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EXECUTIVE  SUMMARY 

1.  This  document  is  approved  for  use  by  all  Departments  and  Agencies  of  the  Department  of 
Defense  (DOD). 

2.  Comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  submitted  for 
improvement  of  this  document  is  addressable  to  the  Information  Processing  Directorate  (Code 
JEBE),  Center  for  Standards  (CFS),  Joint  Interoperability  and  Engineering  Organization  (JIEO), 
Defense  Information  Systems  Agency  (DISA),  10701  Parkridge  Blvd.,  Reston,  VA  20191-4357. 
E-mail  Ms.  Angela  Bcoker  at  bookera@ncr.disa.mil  or  go  to  the  DISA  homepage  at 
Http://www.itsi.disa.mil/.  Please  organize  comments  into  two  categories:  "Essential"  and 
"Suggested."  Please  include  a  recommendation  and  rationale  for  each  proposed  change.  (See 
section  7. 1  for  complete  instructions  about  commenting  on  this  document.) 

3.  The  Information  Technology  Standards  Guidance  (ITSG)  is  a  tool.  Its  purpose  is  to  define  the 
DOD  Open  System  Environment  (OSE)  and  provide  guidance  to  meet  the  requirement  for 
consistent  selection  of  base  standards  for  profiles  for  DOD  Information  Technology  (IT) 
acquisitions.  It  does  this  by  defining  the  DOD  OSE  and  the  target  group  of  IT  standards  that 
DOD  systems  are  to  use  in  implementations.  The  specification  of  the  DOD  OSE  and  the  IT 
standards  contained  within  that  environment  using  the  ITSG  will  guide  system  convergence 
toward  the  DOD-consensus  target  environment. 

4.  The  ITSG  is  the  foundation  document  for  Technical  Architecture  Framework  for  Information 
Management  (TAFIM)  Volume  7,  the  Adopted  Information  Technology  Standards  (AITS).  The 
ITSG  is  a  resource  supporting  the  Joint  Technical  Architecture  (JTA)  and  the  AITS  by  tracking 
activity  in  emerging  standards  that  may  someday  appear  in  the  JTA  or  the  TAFIM.  The  ITSG  also 
provides  more  detailed  information  about  the  standards  adopted  by  the  AITS,  which  is  only  a  list 
of  standards. 

5.  The  ITSG  specifies  the  IT  standards  available  for  each  OSE  base  service  area  (BSA). 

The  ITSG  identifies  formal  and  emerging  standards,  bindings,  public  domain  specifications,  and 
the  interrelationships  among  the  recommended  standards.  It  provides  useful  information  on  the 
recommended  standards  for  each  service  area  such  as  portability  guidance  and  the  recommended 
standard  usage. 
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1.  SCOPE 


1.1  Scope.  The  ITSG  is  intended  for  use  by  system  engineers  and  program  managers  in  planning 
and  procuring  an  open  information  technology  system  by  selecting  standards  profiles.  The  ITSG 
identifies  the  Open  System  Environment  (OSE)  Base  Service  Areas  (BSAs)  and  the  type  and 
status  of  standards  and  specifications  applicable  to  each  BSA.  Any  BSA  can  include  approved, 
open  consensus,  government  standards,  non-government  standards,  consortia  and  industry 
specifications,  and  other  solutions.  It  also  can  include  related  standards  that  may  be  needed  for  a 
particular  OSE  BSA,  caveats  concerning  the  standards  recommended  that  could  jeopardize 
application  portability,  and  information  about  how  to  tailor  procurement  specifications  to  avoid 
portability  problems. 

The  standards  arena  is  broad  and  is  changing  rapidly  enough  to  make  the  ITSG  quickly  obsolete. 
The  ITSG  represents  the  consensus  DOD  target  as  it  was  best  understood  at  the  time  of 
publication.  The  OSE  defined  in  the  ITSG  reflects  the  considerations  and  realities  of  the 
marketplace  and  standards  community.  The  goal  of  the  CFS  is  to  facilitate  decentralized  execution 
of  IT  program  management  leading  to  accomplishment  of  an  enterprise-wide  OSE.  To  that  end, 
the  ITSG  will  be  updated  on  a  recurring  basis  with  sufficient  frequency  to  maintain  its  relative 
currency  and  to  expand  the  thoroughness  of  its  coverage  of  the  IT  domain. 
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2.  GENERAL  REQUIREMENTS 

2.1  Understanding  open  systems  environments. 

2.1.1  The  role  of  standards.  The  fundamental  premise  of  the  ITSG  is  that  the  implementation  of 
well  aligned,  standaids-based  open  systems  will  lead  eventually  to  a  higher  degree  of 
interoperability  and  portability.  Unfortunately,  standards  are  not  yet  defined  for  all  the  basic 
services  needed  for  all  information  technology  systems.  Additionally,  standards  usually  contain 
multiple  options.  Many  standards  allow  options  whose  use  or  disuse  may  result  in  systems  that  are 
compliant  with  the  same  standard  yet  are  not  interoperable  with  one  another. 

Vendors  and  industry  organizations  (i.e.,  consortia)  have  defined  specifications  (to  augment  a 
standard  or  to  compete  with  a  standard)  to  fill  many  gaps  in  the  existing  formal  standards.  These 
specifications  can  provide  some  limited  portability  and  interoperability.  Different  standards- 
defining  groups'  specifications  for  satisfying  the  same  basic  services  sometimes  overlap  and  are 
incompatible  even  disregarding  any  options  they  may  have.  Identifying  the  basic  services  of  a 
system  requires  a  thoughtful  and  thorough  understanding  of  system  requirements  for  current  and 
future  information  technology  environments.  After  identifying  the  basic  services,  the 
recommended  standards  in  the  ITSG  will  provide  a  path  toward  the  DOD  consensus  ooen  system 
environment 

2.1.2  Achieving  practical,  standards- based  open  systems.  A  broad  base  of  available  standards 
is  the  basis  for  achieving  open  systems.  Just  choosing  standards  neither  guarantees  portability  or 
interoperability  nor  guarantees  easy  integration  of  multi-vendor  systems.  Understanding  the 
features  and  options  of  standards  and  knowing  how  to  specify  the  standards  is  vital. 

Information  technology  standards  are  layered  in  the  architecture  between  the  external 
environment  and  the  platform  or  application  environment.  A  well  conceived  architectural 
framework  will  list  its  functional  requirements.  The  ITSG  recommends  standards  intended  to  meet 
the  functional  requirements  of  the  architecture. 

2.1.3  Pitfalls  of  specifying  only  lists  of  standards.  Profiling,  which  is  a  detailed  description  of 
the  selection  of  options  available  within  a  standard,  makes  standards  practical  to  use.  However, 
many  "open  systems  profiles"  are  only  lists  of  standards,  lacking  the  details  to  allow  the  standards 
to  be  implemented  consistently  for  portability  and  interoperability. 

The  specification  of  lists  of  standards  may  indicate  that  the  acquisition  requirements  have  not  been 
identified  or  considered  fully.  The  use  of  standards  requires  the  functional  requirements  of  the 
system  architecture  be  identified  thoughtfully.  The  specification  of  only  existing  standards 
developed  in  a  public  consensus  standards  committees  does  not  take  advantage  of  other  potential 
solutions  available  to  fill  other  functionality  areas  with  some  form  of  standards  implementation 
where  such  formal  standards  do  not  exist.  For  example,  a  Request  for  Proposal  (RFP)  may  specify 
certain  required  Government  standards  or  Non-Government  Standards  (NGS)  and  indicate  those 
areas  for  which  the  bidder  must  propose  standards.  The  system  design  areas  that  have  a 
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functionality  requirement  not  supported  by  adopted  standards  must  be  evaluated  carefully  for  life 
cycle  implications  with  respect  to  the  DOD  open  systems  environment  objective. 

Specification  of  standards  by  their  names  is  not  sufficient  Requirements  exist  for  the 
specification,  use,  and  exclusion  of  specific  dependencies,  extensions,  and  features  that  are 
implementation-defined,  implementation-dependent  undefined,  or  unspecified  within  a  standard. 

A  standard's  libraries,  library  functions,  modes,  options,  and  switch  settings  used  in  the  product 
implementation  of  a  standard  have  portability  implications.  International  Organization  for 
Standardization  (ISO)  TR-10000  and  MIL-HBK-829  cover  the  requirement  for  detailed  profiles 
more  extensively. 

2.1.4  Controlling  the  use  of  specific  features  of  IT  standards.  Standards'  features  (e.g., 
options,  extensions,  levels)  must  be  controlled  within  system  development  Standard  features 
adverse  to  future  system  portability  must  be  excluded.  The  PM  must  exclude  hostile  and  obsolete 
features  of  a  standard  which  will  impede  future  system  portability. 

2.1.5  Conformance  testing.  Testing  implementations  for  conformance  to  a  required  standard  is 
necessary.  Where  National  Institute  of  Standards  and  Technology  (NIST)  conformance  tests 
exist,  validated  products  lists  are  available  that  will  indicate  the  Federal  Information  Processing 
Standard  (FIPS)  and  the  individual  point  of  contact  responsible  for  the  standard's  conformance 
testing  progiam.  A  NIST  report  on  conformance  testing  and  validated  products  can  be  located  at 

ftp://speckle.ncsl.nist.gov/vpl/intro.htm. 

The  Open  Group  (X/Open)  validates  products  through  its  branding  program.  More  information 
regarding  X/Open  branded  products  can  be  located  at  URL  http://opengroup.org/. 

The  DOD's  Joint  Interoperability  Test  Command  (J1TC)  maintains  a  list  of  products  it  has  tested. 
The  list  can  be  located  at  URL  http://jitc-emh.army.mil/register.htm. 

2.1.6  Relationship  Between  ITSG  Standards  and  Weapon  System  Standards.  The  standards 
in  the  ITSG  have  a  much  broader  range  of  applicability  than  just  information  processing  systems. 
They  are  equally  applicable  to  other  systems,  such  as  weapon  systems.  ITSG  standards  in  major 
service  areas  such  as  data  interchange,  operating  systems,  and  security  are  as  needed  by  many 
weapon  systems  as  Mission  Critical  Computer  Resources  (MCCR)  standards  are. 

Among  the  major  service  areas  of  the  ITSG  that  contain  standards  useful  to  military  weapon 
systems  are  user  interface  (e.g.,  keyboard  device  layout,  user  interface  style  guides),  data 
management  (e.g.,  data  dictionary/directory  services),  data  interchange  (e.g.,  physical  interface, 
image  data  interchange,  geospatial  data  exchange,  tactical  communications),  graphics  (e.g., 
symbology  graphics),  communications,  (e.g.,  connectionless  service),  operating  systems  (e.g.,  real 
time  services  and  interfaces),  system  management  (e.g.,  fault  monitoring),  and  security  (e.g., 
authentication). 
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The  major  service  areas  in  the  ITSG  are  covered  in  detail  in  Section  3,  Detailed  Requirements. 
Because  it  is  so  large,  Section  3  is  divided  by  major  and  spanning  service  areas  into  separate  parts 
of  this  document  After  reading  part  one,  the  Introduction/Guide,  the  user  can  treat  the  ITSG 
more  like  an  encyclopedia,  exploring  the  standards  'elutions  for  service  areas  of  interest 
Table  2.2-1  lists  the  sections  and  the  seven  major  and  six  spanning  service  areas  along  with  the 
CFS  point  of  contact  (POC)  for  each.  ITSG  parts  2  through  8  list  the  major  service  areas;  parts  9 
through  14,  the  spanning  service  areas.  Sections  5. 1.4.2  and  5.2.2  contains  further  information 
regarding  spanning  and  major  service  areas. 


TABLE  2,2-1  Mapping  service  areas  to  parts 


Paragraph 

Service  Area 

rrsG 

Part 

1,2,  3.1, 4,  5,  6,  7 

Introduction/Guide 

Ms.  Angela  Booker,  JEBEA 

1 

3.2 

Mr.  Jim  Barnette,  JEBEB 

2 

3.3 

User  Interface 

3 

3.4 

Data  Management 

Dr.  Dan  Wu,  JEBEB 

4 

3.5 

Data  Interchange 

Mr.  Alan  Peltzman,  JEBEB 

5 

3.6 

Graphics 

Mr.  Alan  Peltzman,  JEBEC 

6 

3.7 

Communications 
and  Network 

Mr.  Ralph  Liguori,  JEBBD 

7 

3.8 

Operating  Systems 

Mr.  Curtis  Royster,  JEBEB 

8 

3.9 

System  Management 

Mr.  Larry  Spieler,  JEBEA 

9  ij 

3.10 

Security 

Mr.  Jim  Barnette,  JEBEB 

10 

3.11 

Distributed 

Computing 

Dr.  Dan  Wu,  JEBEB 

>1  i 

3.12 

Multimedia 

Dr.  Doris  Bemardini,  JEBEB 

12 

3.13 

Human  Factors 

Hi 

3,4 

internationalization 

Ms.  Angela  Booker,  JEBEA 

14 

Each  major  service  area  in  parts  2  through  14  is  decomposed  into  dozens  of  smaller  service  areas 
called  BSAs.  There  are  additional  services  below  the  base  standard,  but  the  ITSG  does  not 
attempt  to  represent  them.  These  lower  levels  usually  involve  only  small  parts  of  standards,  not 
entire  documents.  Every  BSA  within  the  anticipated  DOD  Open  System  Environment  is  in  the 
ITSG.  For  a  DOD  system  or  architecture  to  proceed  toward  an  open  system  goal,  the 
architectural  requirer  ents  of  the  system  must  match  up  to  these  BSAs.  The  BSAs  also  show 
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some  logical  relationships  that  lead  to  identifying  mid-level  service  areas  within  the  major  service 
areas. 


For  example,  the  Data  Management  Services  major  service  area  breaks  down  into  mid-level 
service  areas  as  follows: 

a.  Data  management  system 

b.  Data  management  security 

c.  Data  dictionary/directory  services 

d.  Distributed  data 

e.  Object  database 

f.  Transaction  processing. 

Within  the  mid-level  service  area  called  "data  management  system,"  the  ITSG  contains  the 
following  OSE  BSAs.  An  example  of  one  of  these  OSE  BSAs  follows  in  section  2.3. 

a.  Basic  database  services 

b.  Indexed  sequential  access 

C.  Electronic  forms 

d.  Report  writer 

e.  Database  administration 

f.  Menu-driven  database  access 

g.  Data  storage  and  archiving 

h.  Multidatabase  APIs. 
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2.3  How  to  use  the  1TSG.  The  BSA  descriptions  are  the  focus  of  the  use  of  the  ITSG.  These 
descriptions  are  in  parts  2  through  14.  The  major  and  mid-level  service  area  descriptions  are  no 
more  than  definitions  of  the  logical  links  binding  all  the  BSAs  grouped  beneath  them. 

A  BSA  is  a  logical  entity  within  the  OSE  that  requires  some  form  of  standards  solution  although 
not  all  BSA  descriptions  have  standards  solutions  yet  Some  standards  logically  fall  within  a 
specific  BSA.  In  other  cases,  different  BSAs  sometimes  list  the  same  standards  because  a 
particular  standard  satisfies  more  than  one  BSA  requirement  For  each  BSA  identified,  there  is  a 
brief  definition  of  the  BSA,  and  the  following  topics  are  addressed: 

3.X.Y.Z.1  Standards 

3.X.Y.Z.2  Alternative  specifications. 

3.X.Y.Z.3  Standards  deficiencies 
3.X.Y.Z.4  Portability  caveats 
3.X.Y.Z.5  Related  standards 
3.X.Y.Z.6  Recommendations. 

In  each  BSA  there  are  five  paragraphs  giving  additional  explanation  of  the  standards  listed  in  the 
standards  table  of  the  first  paragraph.  The  standards  listed  in  the  top  rows  (labeled  DOD 
"mandated"  or  "adopted")  are  given  primary  emphasis.  The  text  is  intended  to  support  primarily 
the  mandated  standard.  Information  about  the  remaining  standards  provides  assistance  for  the 
DOD  legacy  systems  that  may  continue  to  use  other  standards  during  their  transition  to  the  DOD 
OSE  target  environment.  In  those  sections  for  which  no  information  can  be  reported  at  present,  a 
short  statement  will  appear  stating  that  there  is  no  known  or  reported  information  on  this  topic. 
Information  may  be  added  in  future  versions  of  the  ITSG.  An  example  of  text  that  corresponds  to 
the  example  standards  table  follows  in  sections  2.3.2  through  2.3.6. 

2.3.1  Paragraph  one:  Standards.  The  first  sub-part  of  the  BSA  description  is  the  standards 
table.  The  standards  table  is  the  key  to  using  the  ITSG.  These  tables  include  all  applicable 
standards  satisfying  the  BSA.  The  intent  is  to  list  all  of  the  standards  that  may  be  used  within 
DOD  to  prepare  for  the  non-open  legacy  systems  that  will  be  migrating  toward  open  systems. 
These  systems  may  implement  standards  other  than  the  recommended  ones. 

It  is  important  to  remember  that  the  standards  table  is  not  a  stand  alone  expression  of  the  DOD 
OSE  recommendation.  Paragraph  six,  the  recommendation,  must  also  be  consulted  for  the 
rationale  for  the  recommendation.  Each  table  must  be  viewed  in  the  context  of  the  additional  text 
provided  in  the  BSA  to  understand  fully  the  recommend-hon  and  its  implications. 

The  following  features  in  the  standards  table  require  further  explanation: 

a.  Standards  types  and  hierarchy  of  standards 

b.  Standards  entries 

c.  The  DOD  adopted  information  technology  standard 

d.  The  "Gray  Zone." 
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23.1.1  ITSG  standards  type  definition.  The  ITSG  defines  standards  types  using  three 
descriptors.  These  descriptors  define  the  sc  '  e  of  the  sponsoring  body,  die  availability  of  the 
specification,  and  the  method  of  change  control  in  defining  or  redefining  the  specification.  This 
standards  type  definition  is  most  useful  for  distinguishing  among  the  many  kinds  of  public 
specifications  that  are  preferred  in  the  aftermath  of  the  cancellation  of  MIL-STD-970. 

2. 3. 1.1.1  Scope.  This  identifies  the  range  of  'ntended  applicability  of  the  specification,  determined 
largely  by  the  sponsoring  body.  The  permitted  values  for  the  scope  descriptor  are  International, 
National,  Government,  Consortium,  or  Corporate.  The  latter  value  identifies  specifications 
created  by  a  single  company  for  their  own  use  but  which  may  be  available  to  others.  Examples  of 
this  type  include  data  storage  formats  specific  to  software  products. 

2J.I.1.1.1  International.  Standards  of  intr'tational  scope  are  NGS  created  by  accredited 
international  NGSBs.  For  NGS,  there  is  an  order  of  precedence  cited  by  the  IEEE  in  P1003.0, 
and  adapted  here.  The  order  is  international  standards,  regional  standards,  national  standards, 
draft  versions  of  the  preceding,  open  forum  standards  (e.g.,  professional  group  standards,  trade 
association,  industry,  consortia),  emerging  (t  g.,  committee  documents,  draft  regional  or  national 
standards),  and  de  facto.  Typical  international  NGSBs  include  the  International 
Telecommunications  Union  (ITU)  and  International  Organization  for  Standardization  (ISO). 

2.3.1.1.1.2  National.  Standards  of  national  scope  are  NGS  created  by  accredited  national 
NGSBs.  Typical  national  NGSBs  include  the  Institute  for  Electrical  and  Electronics  Engineers 
(IEEE)  and  American  National  Standards  Institute  (ANSI). 

2.3.1.1.1.3  Government.  Standards  of  government  scope  are  those  standards  developed  or 
adopted  by  departments  and  agencies  of  the  Federal  government.  These  standards  can  be  and 
often  are  identical  to  existing  NGS.  At  times,  the  government  mandates  specific  standards  by  law. 
The  most  important  part  of  mandated  standards  (for  ranking  purposes)  is  the  source  of  the 
mandate,  whether  by  law  (F  IPS),  DOD  (JTA  or  OSD  Directive),  treaty  and/or  international 
military  standardization  af/cement  (e.g.,  NATO  STANAG,  Air  Standardization  Coordinating 
Committee),  In  this  document,  the  only  rr  ary  standards  are  those  mandated  by  the  JTA,  and 
those  JTA  mandated  standards  come  first  >  cedence.  (See  para.  2.3. 2.3. 5. 1.1  for  a  description 
of  Mandated  status.' 

2.3.1. 1.1.4  Consortia.  Consortia  include  organizations  not  formally  recognized  and  accredited  to 
make  standards.  Suppliers  and  users  of  information  technology  unite  to  create  consortia 
standards.  Increasingly,  consortia  -re  defining  specifications  that  provide  needed  extensions  to 
national  and  international  standards  because  these  standards  bodies  cannot  anticipate  users’ 
requirements  in  all  aspects  of  computing  and  define  standards  quickly  enough.  Sometimes  these 
extensions  arise  from  the  NGSBs’  inability  to  agree  on  a  proposed  portion  of  a  standard. 

Consortia  specifications  also  are  created  in  response  to  the  absence  of  standards  for  a  needed 
service. 

Consoma  specifications  achieve  consensus  outside  of  accredited  NGSBs  and  use  a  consensus 
process  for  their  maintenance.  This  consensus  process  of  creating  specifications,  while  not  entirely 
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open  (sometimes  open  only  to  trade  associations,  industry  groups,  and  individual  vendors), 
enables  products  that  support  portability  and  interoperability  to  be  implemented.  Many  standards- 
creating  consortia  use  a  consensus  process  to  maintain  the  standard,  although  the  process  may  not 
be  open.  Also,  such  maintenance  decreases  the  chances  the  applications  and  platforms  become 
incompatible. 

These  specifications  frequently  become  the  basis  for  standards  from  NGSBs  later  (e.g.,  OSF's 
Motif  specification  became  the  basis  for  IEEE  1295. 1).  Most  consortia  specifications  are  available 
now,  do  not  overlap  with  or  conflict  with  an  existing  NGS  or  NGS  under  development,  and 
exercise  no  restraint  (except  perhaps  cost)  on  who  can  use  the  specifications  or  how  they  can  use 
them. 

23.1.1.1.5  Corporate.  Software  developers  also  develop  standards  for  their  own  use  that  are  not 
generally  consensus  standards.  These  are  incorporated  in  software  products,  achieve  a  high 
degree  of  popularity,  and  become  known  as  de  facto  standards.  The  specifications  for  these 
systems  are  under  proprietary  control.  A  vendor's  unilateral  change  to  their  corporate  standard 
may  make  other  vendors'  products  and  applications  that  originally  were  compatible  incompatible. 
Proprietary  or  corporate  standards  are  to  be  used  only  when  no  available  commercial  or 
government  standards  will  support  the  requirement  Acquisition  policies  prohibit  using  such 
specifications  in  the  same  manner  that  the  other  standards  in  an  RFP  are  used.  The  ITSG  does  not 
recommend  nor  specify  corporate  standards. 

23.1 1.2  Availability.  This  identifies  whether  the  specification  is  available  to  the  Public,  or  if  it  is 
Private.  In  order  to  be  Public,  a  specification  must  be  available  to  anyone  for  a  reasonable  cost 
(i.e.,  for  reproduction  cost).  Specifications  that  are  only  available  to  dues-paying  members  of  a 
consortium  are  Private.  Payment  for  a  standard  on  a  license  basis  rather  than  dues  payment  to  a 
group  also  belongs  to  the  Private  category. 

23.1.13  Change  control.  This  identifies  whether  changes  are  controlled  by  a  Consensus  or  Non¬ 
consensus  process.  Accredited  NGSBs  and  the  government  produce  standards  controlled  by  a 
consensus  process,  since  the  affected  organizations  are  given  a  chance  to  express  comments 
before  the  standard  is  approved.  A  consortium  may  be  considered  to  have  a  consensus  process  if 
the  membership  of  the  consortium  is  not  restrictive  (other  than  by  the  cost  of  membership).  A 
specification  controlled  by  a  single  profit-making  organization  is  not  changed  by  a  consensus- 
based  process. 

23.1.1.4  Abbreviations.  Some  of  the  most  used  standards  types  will  appear  in  abbreviated  form. 
These  types  and  their  abbreviations  are: 

Corporate  Private  Non-Consensus  (CPN-C) 

Consortia  Public  Consensus  (CPC) 

Government  Public  Consensus  (GPC) 

Internationa!  Public  Consensus  (IPC) 

National  Public  Consensus  (NPC) 
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2.3. 1.2  Standards  entries.  This  section  describes  the  entries  in  the  different  columns  of  each 
standards  entry  in  the  standards  table. 

1.3.U.1  Standard  type.  The  first  column  in  the  standard  entry  is  the  standard  type  as  discussed 
in  2.3.1. 1,  ITSG  standards  type  definition,  above. 

2.3.1.2.2  Sponsor.  This  column  identifies  the  organization  sponsoring  or  controlling  changes  to 
the  specification  or  standard.  Typical  sponsors  are  ISO,  ANSI,  IEEE,  NIST,  or  X/Open. 

23.UJ  Standard.  This  column  identifies  the  standard  or  specification  by  name.  Many  standards 
with  different  designations  are  identical  (e.g.,  standards  adopted  by  multiple  standards  bodies 
without  changes).  A  specific  example  is  IEEE  Std.  1 003. 1  - 1 990,  which  ISO  later  adopted  as 
ISO/1EC  9943-1: 1990,  and  NIST  as  FIPS  PUB  151-2.  The  standards  tables  contain  all  the 
references  to  identical  standards  in  separate  rows  using  each  of  their  different  designations.  If  the 
specification  is  the  same  as,  or  derived  from  another  standard,  the  relationship  is  indicated  with 
comments  to  the  effect  in  the  same  column.  This  approach  toward  matching  standards  has  been 
chosen  for  informative  reasons. 

2.3. 1.2.4  Standard  reference.  This  column  contains  a  formal  citation  for  the  standard  or 
specification.  The  citation  must  include  a  version  number  and  date,  if  necessary  to  unambiguously 
identify  the  specification. 

2.3. 1.2.5  DOD  status  (Life  Cycle  status).  This  column  identifies  the  status  of  the  specification, 
from  concept  to  obsolescence.  This  column  identifies  both  the  DOD  status  and  the  ITSG  life  cycle 
status.  The  allowable  values  for  each  type  of  status  reported  are  discussed  in  the  sections  that 
follow.  All  entries  in  the  tables  show  the  life  cycle  status  in  parenthesis.  DOD  status  may  or  may 
not  apply  to  the  standard. 

2. 3.1. 2.5.1  DOD  status.  This  part  of  the  DOD  status  (Life  Cycle  status)  column  refers  to  the 
approval  for  use  of  a  standard  in  the  DOD  community  according  to  the  JTA  or  the  TAFIM.  DOD 
status  terms  include  mandated,  adopted,  emerging,  legacy,  and  informational.  These  terms  are 
discussed  in  the  following  subparagraphs. 

2.3.1.2.5.1.1  Mandated.  The  DOD  status  "Mandated"  is  used  for  those  standards  mandated  by 
the  JTA.  A  standard  is  mandatory  in  the  sense  that  IF  a  service/interface  is  going  to  be 
implemented,  it  shall  be  implemented  in  accordance  with  the  associated  standard.  If  a  required 
service  can  be  obtained  by  implementing  more  than  one  standard,  the  appropriate  standard  should 
be  selected  based  on  system  requirements.  Mandated  standards  appear  in  the  top  rows  of  the 
standards  tables  in  the  ITSG  and  are  bordered  with  heavy  black  lines. 

2.3.1.2.5.1.2  Adopted.  The  DOD  status  "Adopted"  is  used  to  mean  that  the  standard  in  the  ITSG 
is  approved  by  DOD  for  use  in  satisfying  each  function  of  the  BSA  where  there  exists  no  JTA 
mandated  standard.  Adopted  standards  may  be  implemented  but  shall  not  be  used  in  lieu  of  a 
mandated  standard.  Adopted  standards  also  appear  in  the  top  rows  of  the  standards  tables  in  the 
ITSG  and  are  bordered  with  heavy  black  lines. 
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23.1.2.5.1.3  Emerging.  According  to  the  JTA,  a  DOD  "Emerging"  status  denotes  a  candidate 
standard  to  be  added  as,  or  to  replace,  a  mandated  standard.  This  includes  standards  required  to 
capitalize  on  new  technologies.  These  candidates  will  help  the  program  manager  determine  those 
areas  that  are  likely  to  change  in  the  near  term  (within  three  years)  and  suggest  those  areas  in 
which  "upgradability"  should  be  a  concern.  The  expectation  is  that  emerging  standards  will  be 
elevated  to  mandated  status  in  the  JTA  when  implementations  of  the  standards  mature.  Emerging 
standards  may  be  implemented  but  shall  not  be  used  in  lieu  of  a  mandated  standard. 

2.3.1Ji.U  Legacy.  A  "Legacy"  standard  is  a  standard  necessary  to  achieve  or  maintain 
interoperability  with  legacy  systems.  Legacy  systems  are  systems  that  are  in  current  use.  Legacy 
standards  are  not  recommended  for  future  procurements.  Legacy  standards  may  be  supported 
until  the  legacy  system  is  no  longer  being  maintained.  An  example  of  a  legacy  standard  is  the 
X.25  packet  switching  standards. 

2 -3.1.2 .5.1.5  Informational.  Informational  standards  include  those  remaining  standards  that  fall 
outside  the  official  DOD  statuses  of  "mandated,"  "adopted,"  "emerging,"  and  "legacy." 

2.3.1. 2.5.2  Life  Cycle  status.  This  part  of  the  DOD  status  (Life  Cycle  status)  column  defines 
the  life  cycle  status  of  the  standard,  as  established  by  the  originator  of  the  standard. 

2.3.1.2.5.2.1  Approved.  The  specification  has  been  approved  and  published  by  its  sponsoring 
body.  This  status  is  only  meaningful  for  consensus-based  specifications  and  standards. 

2.3.1.2.5.2.2  Superseded.  Superseded  standards  were  formerly  approved  but  have  now  been 
replaced,  either  by  a  later  version  of  the  standard  or  by  the  progress  of  technology.  Superseded 
standards  are  not  often  desirable,  but  rank  ahead  of  any  non-approved  standard.  Superseded 
standards  appear  only  at  the  bottom  of  the  standards  table. 

2.3.1.2.5.2.3  Draft.  The  specification  has  been  defined  and  is  being  reviewed.  If  this  is  a  public, 
consensus  standard,  the  specification  should  be  available  for  comment.  Draft  standards  are  often 
subject  to  significant  change  before  approval. 

Further  notes  are  appended  to  clarify  the  status  of  a  draft,  including  the  ISO  stages  of 
development  (e.g.,  CD,  WD,  DIS)  or  if  the  standard  is  in  ballot. 

Draft  standards  appear  only  at  the  bottom  of  the  standards  table. 

2.3.1.2.5.2.4  Formative.  The  specification  is  in  the  process  of  being  defined.  Generally,  a 
committee  has  been  formed  to  create  the  standard,  but  the  specification  has  not  stabilized.  It  is  not 
available  to  the  public.  Formative  standards  appear  only  at  the  bottom  of  the  standards  table. 

2.3.1.3  The  top  row.  The  top  rows  of  the  standards  table  contain  the  DOD  mandated  or  adopted 
information  technology  standard  satisfying  that  particular  BSA.  These  standards  are  surrounded 
by  a  heavy  black  line  and  the  standards  are  the  same  ones  presented  in  the  Adopted  Information 
Technology  Standards  (TAFIM  Volume  7). 
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The  remaining  five  parts  of  the  BSA  description  provide  additional  and  necessary  information 
about  the  target  standard  and  the  other  standards  listed  in  the  table.  The  extensive  information 
about  the  standards  population  within  a  specific  BSA  provides  a  full  perspective  of  the  activity  ji 
that  area.  The  standards  in  the  lower  rows  are  provided  in  case  an  acquisition  cannot  use  the 
standard  specified  in  the  top  row.  For  example,  they  may  be  transitional  systems  in  which  a 
portion  of  a  legacy  system  will  remain  unchanged  temporarily. 

If  a  standard  listed  in  a  lower  row  is  specified  in  an  acquisition,  then  the  acquired  system  will 
diverge  from  the  target  DOD  OSE.  Standards  listed  in  the  lower  rows  of  the  tables  diminish  the 
probability  of  achieving  portability  and  interoperability  and  may  increase  the  ultimate  life-cycle 
cost  required  to  achieve  an  open  system  state. 

If  a  system  cannot  use  the  standard  specified  in  the  top  row,  then  it  would  be  preferable  to  use  a 
standard  listed  in  a  lower  row,  but  within  the  standards  table  if  possible.  If  a  standard  listed  in  a 
lower  row  is  specified,  there  is  risk.  This  risk  is  two-fold.  If  an  emerging  standard  listed  in  a  lower 
row  is  specified,  the  emerging  standard  may  fail  to  arrive  in  the  marketplace  in  the  same  form 
within  a  product.  If  the  system  implementation  uses  a  declining  standard  of  diminishing  use  and 
popularity,  there  is  a  risk  that  the  products  implementing  the  standard  may  be  dropped  by  vendors 
as  they  move  toward  the  standard  listed  in  the  top  row.  Projects  using  standards  not  consistent 
with  the  target  standards  identified  in  this  document  preclude  the  levels  of  portability  and 
interoperability  required  to  satisfy  these  stated  DOD  requirements.  Also,  the  teut  accompanying 
the  BSA  contains  further  needed  guidance  for  a  solution. 

The  standards  tables  of  some  BSAs  show  what  may  be  considered  a  paradoxical  situation.  There 
may  be  more  than  one  "top  row"  standard.  This  occurs,  for  example,  in  the  geospatial  data  area 
where  different  data  sets  are  appropriate  to  different  map  scales.  This  situation  shows  that  more 
than  one  standard  may  be  preferred  depending  on  specific  architectural  requirements.  Often  these 
multiple  standards  are  complementary  and  all  could  be  chosen  to  achieve  the  desired  results. 

2.3.1.4  The  bottom  area.  The  contents  of  every  standards  table  in  the  1TSO  will  change  as  a 
reflection  of  industry  dynamics  as  standards  become  formalized  and  are  drafted,  or  become 
obsolete  and  superseded.  The  bottom  area  in  the  tables  depicts  this  rise  and  fall  of  standards.  The 
bottom  area  can  contain  standards  with  life-cycle  statuses  superseded,  formative,  and  draft  with 
DOD  statuses  emerging,  legacy,  or  informational.  The  specification  of  standards  within  the 
bottom  area  involves  risk.  These  standards  are  only  an  option  in  the  case  where  no  suitable  NGS 
is  listed  in  the  upper  rows.  Populated  bottom  areas  tend  to  show  up  in  established  BSAs 
containing  many  different  standards. 

2.3.1.5  Example  table.  All  standards  found  in  the  remaining  parts  of  the  ITSG  are  combined 
under  section  3.X.Y.Z.  1  into  a  single  table.  Table  2.3- 1  gives  an  example  of  a  standards  table 
using  a  BSA  from  the  example  of  the  ITSG  structure  in  section  2.2.  Note  that  Table  2.3-1  and 
figures  2.3-1  through  223-5  are  to  be  used  as  examples  and  not  as  the  official  finding*  of  the 
BSA  used  in  these  examples. 
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In  the  example  of  a  standards  table  below,  the  top  row,  or  DOD  mandated  standard,  is  NIST 
FIPS  127-2,  specifying  Database  Language  SQL.  This  version  of  the  SQL  standard  uses  ANSI 
X3.13S-1992  and  ISO  9075:1992.  The  mandated  standard  has  precedence  over  all  other  entries  in 
the  table  and  should  be  used.  The  first  entry  in  the  bottom  area  of  the  example  table  is  in  draft 
(CD)  life-cycle  status  and  is  DOD  informational.  Risk  is  less  for  this  draft  standard  than  for  the 
DOD  informational  superseded  standard  appearing  in  the  bottom  area.  The  superseded  life-cycle 
standard  has  been  replaced  and,  therefore,  involves  much  risk,  if  used.  (In  fact,  it  should  not  be 
used  at  all.)  The  last  entry  in  the  bottom  area  has  a  draft  life-cycle  status  with  DOD  informational 
status.  As  is  noted,  it  may  eventually  replace  SQL2.  This  last  standard  will  be  moved  out  of  the 
bottom  area  if  and  when  it  is  approved  by  its  sponsoring  body.  If  JTA  decides  to  add  it  to  its 
emerging  list,  then  the  DOD  status  "emerging"  will  replace  the  "informational"  DOD  status.  The 
standard  would  then  appear  above  the  bottom  area  as  DOD  emerging  with  life-cycle  status  of 
approved.  [Note:  Risk  factors  are  usually  different  for  each  information  system.  It  is  the 
responsibility  of  the  program  manager  to  determine  risk  by  performing  a  risk  analysis.  Risk 
determination  is  beyond  the  scope  of  the  ITSG.J 


TABLE  2.3-1  Example  table  of  basic  database  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DOD 

(Life  Cycle) 

GPC 

NIST 

■»  gg  an  g  i  agggg 

FIPS  127*2:1993 

Mandated 

(Approved) 

IPC 

ISO 

Database  Language  SQL  (tame  as  ANSI  X3.13S-1992) 

9075:1992 

Informational 

(Approved) 

NPC 

ANSI 

Database  Language  SQL  (tame  u  ISO/IEC  9075:1992) 

X3.135:1992 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Functional  Specifications  for  Database 
Management  Systems 

FIPS  124:1986 

Informational 

(Approved) 

CPC 

X/Open 

Embedded  SQL  (COBOL  and  C) 

SQL  Developers 
Specification 

Inform  atiotul 
(Afroroved) 

IPC 

ISO 

Database  Language  •  Network  (NDL) 

8907:1987 

Informational 

(Approved) 

GPC 

NIST 

Database  Language  -  NDL  (adopts  ANSi  X3. 1 33- 1 986) 

FIPS  126:1987 

Informational 

(Approved) 

NPC 

ANSI 

Database  Language  -  (NDL) 

X3.133:I986 

Informational 

(Approved) 

CPC 

X/Open 

Data  Management;  Reference  Model 

G505  (10/95) 

Informational 

(Approved) 

BC 

WMfC 

9073 

.  Wotmati  ^pd  | 
(Draft*  )> 

355= 

cast  awn 

■\  -  i 

\  y  ■  \ ' 

S, '  ■  g jj  | 

£1119: 

ANSI  ' 

“ .... 
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2.3.2  Paragraph  two:  Alternative  specifications.  The  "Alternative  specifications"  section 
identifies  other  specifications  that  can  satisfy  the  BSA.  These  will  often  be  de  facto  specifications 
or  vendor  products  that  are  de  facto  standards  and  other  specifications  not  defined  in  formal 
standards  groups.  The  DOD  and  ITSG's  policy  is  generally  NOT  to  recommend  such 
specifications.  The  alternative  specifications  indicate  the  types  of  solutions  likely  to  be  offered  if 
no  other  specifications  exist 

FIGURE  2.3-1  Alternative  specifications  text  example 

The  following  alternative  specifications  are  available: 

a.  For  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and  dynamic 
facilities  standards:  Integrated  Database  Application  Programming  Interface  (IDAPI),  a 
specification,  published  by  Borland,  IBM,  Novell,  and  Word  Perfect  Corporation,  will 
allow  DOS,  OS/2,  and  Windows  applications  to  access  a  variety  of  SQL  and  non-SQL 
databases  transparently. 

b.  No  applicable  consortia  or  de  facto  SQL  integrity  constraint  specifications  are  available. 

c.  For  X/Open  SQL  and  the  IBM  Systems  Application  Architecture  (SAA)  SQL  support 
Embedded  C. 

d.  For  dynamic  facilities  the  only  oth„r  available  specifications  are  proprietary. _ 


In  the  alternative  specifications  example,  several  alternatives  are  mentioned,  but  they  are  not 
appropriate  considering  the  availability  of  SQL  in  FIPS  127-2 

2 .3.3  Paragraph  three:  Standards  deficiencies.  This  section  identifies  deficiencies  in  the 
standards  and  recommends  how  to  apply  the  standard  to  reduce  their  impact.  "Standards 
deficiencies"  addresses  known  problems  within  the  standards  such  as  missing  features.  In  those 
cases  where  this  section  is  absent,  no  deficiencies  have  been  identified  for  inclusion,  but  does  not 
suggest  the  standards  have  no  deficiencies. 

FIGURE  2.3-2  Standards  deficiencies  text  example 
The  following  deficiencies  in  the  standards  have  been  identified: 

a.  For  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and  dynamic  facilities 
standards: 

(1)  No  standardized  way  exists  to  specify  logical  database  access  control,  which  is  important 
to  database  security. 

(2)  Hashing  methods  to  access  data  are  neither  standardized  nor  in  progress. 

(3)  SQL1  is  inadequate  and  has  failed  to  be  transportable  or  standardized  to  be  very  useful. 
The  upcoming  SQL-3  provides  an  opportunity  for  DOD  requirements  to  be  inserted. 

b.  For  data  integrity  standards,  SQL  Integrity  Enhancement  is  a  simple  capability  with  no 
constructs  to  help  programmers  maintain  data  consistency. 

c.  For  Embedded  SQL  standards,  SQL2  supports  Embedded  SQL  in  C  and  Ada.  However, 
products  will  not  be  available  for  some  time.  International  Organization  for  Standardization 
(1SQ)/American  National  Standards  Institute  (ANSI)  Embedded  SQL  does  not  support  the 
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FIGURE  2.3-2  Standards  deficiencies  text  example  (cont'd.) 

C  programming  language.  The  use  of  embedded  SQL  requires  a  precompiler  for  each 
language  in  which  SQL  is  embedded. 

d.  For  dynamic  facilities  standards,  deficiencies  in  the  existing  formal  standards  are  unknown. 

e.  For  SQL  environments,  the  emphasis  in  this  first  FIPS  for  SQL  Environments  is  on  profiles 

for  limited  SQL  interfaces  to  non-SQL  data  repositories.  Subsequent  versions  of  this  FIPS 
may  specify  more  complete  profiles  for  other  products  in  an  SQL  environment.  The  profiles 
defined  by  this  standard  are  not  complete  in  and  of  themselves.  The  user  is  required  to  add 
information  before  this  standard  can  be  successfully  used  in  a  procurement _ 

In  the  standards  deficiencies  example  above,  several  problems  with  the  existing  standards  have 
been  identified.  In  this  example,  no  deficiencies  in  FIPS  PUB  127-2  have  been  identified. 

2.3.4  Paragraph  four:  Portability  caveats.  "Portability  caveats"  addresses  the  features  of  the 
standard  hindering  portability.  In  those  cases  where  this  section  is  absent,  no  portability  problems 
have  been  identified,  but  the  absence  of  portability  caveats  does  not  suggest  the  standards  have  no 
portability  problems. 

The  portability  caveats  example  points  out  particular  problems  of  the  SQL  standards: 
implementation-defined  exception  code  values  and  the  character  data  type.  Additional  portability 
problems  arise  between  the  NIST  FIPS  for  SQL  and  the  other  versions  of  the  standard  as  shown 
in  the  text  (See  Figure  2.3-3). 

FIGURE  2.3-3  Portability  caveats  text  example 


The  following  portability  caveats  apply: 

a.  For  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and  dynamic  facilities 

standards, 

(1)  SQL  2's  segmentation  into  multiple  levels  increases  the  likelihood  of  incompatibility 
between  different  vendors'  SQLs,  because  different  vendors  will  implement  entry  level 
SQL  2,  then  choose  options  from  other  levels. 

(2)  The  ISO,  ANSI,  and  Federal  Information  Processing  Standard  (FIPS)  versions  of  SQL 
specify  state  exception  code  values  (called  SQLCODE  parameters)  such  as  0  for 
successful  execution,  100  for  nonexistent  data,  and  implementation  defined  code  values 
for  particular  exception  conditions.  Different  products  that  conform  with  SQL  have 
different  SQLCODE  values  for  exception  conditions.  The  set  of  SQL  character  values  for 
the  character  data  type  and  collating  sequence  of  characters  is  defined  by  the  implementor, 
the  implementor,  and  therefore,  nonstandard  in  products. 

b.  For  data  integrity  the  following  portability  caveats  apply: 

(1)  Most  vendors'  products  contain  extensions.  To  maximize  portability,  reduce  the  use  of 
extensions  as  much  as  possible. 

(2)  Different  vendors  provide  locking  to  different  degrees  of  granularity.  Portability  and/or 

; _ interoperability  of  applications  result  in  locking  to  the  largest  degree  of  granularity. _ 
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FIGURE  2.3-3.  Portability  caveats  text  example  (cont’d.) 

c.  For  dynamic  facilities  the  following  portability  caveat  applies:  Although  the  X/Open  and  SAA 
SQLs  support  dynamic  SQL,  X/Open  SQL  is  an  X/Open-enhanced  specification  of  the  1986 
version  of  Level  1  SQL,  while  SAA  SQL  is  not  fully  ISO/ANSI  SQL  compatible,  although  it 
will  be.  Also,  X/Open  and  SAA  dynamic  SQL  facilities  are  not  fully  compatible  with  each 
other. 

d.  For  SQL  environments,  conformance  testing  for  products  claiming  conformance  to  one  of  the 

profiles  specified  by  FIPS  193  will  be  achieved  by  a  suitable  modification  of  the  existing  NIST 
SQL  test  suite.  This  FIPS  requires  the  customer  to  choose  from  among  the  different  binding 
styles  already  defined  by  the  SQL  standards.  Two  of  these  styles  (CLI  and  RDA)  are  expected 
to  be  more  popular  than  the  others.  If  a  programming  language  binding  style  is  chosen,  then 
FIPS  SQL  specifies  the  parameter  passing  requirements  for  each  of  seven  different 
programming  languages. _ 

2J.5  Paragraph  five:  Related  standards.  The  related  standards  section  addresses  the  standards 
required  as  a  foundation  for  a  particular  standard,  or  other  standards  relating  to  the  functionality 
under  discussion,  or  other  interfacing  standards.  A  prime  example  of  this  would  be  IEEE  Std. 

1003. 1-1990  as  a  related  standard  for  using  IEEEP1003.1b,  which  is  the  real  time  extension  to 
the  1003.1  standard. 

In  the  related  standards  example,  standards  usable  to  extend  SQL  functionality  have  been 
identified.  These  standards  include  Remote  Database  Access  (RDA),  and  all  may  be  found  in  the 
standard  tables  of  other  BSAs  in  section  3.4.  (See  Figure  2.3-4). 

FIGURE  2.3-4  Related  standards  text  example 

The  following  standards  are  related  to  basic  database  services  or  basic  database  service  standards: 

(1)  ISO  9579-1:  Remote  Database  Access  (RDA)  (Generic  Model,  Service  and  Protocol) 
(supports  remote  database  access  in  client-server  environments) 

(2)  ISO  9579-2:  RDA:  (SQL  Specialization) 

(3)  SQL  Access  Group's  (SAG's)  SQL  Access  Formats  and  Protocols  (FAP)  (1991) 

(4)  SAG's  Call  Level  Interface  (CLI) 

(5)  X/Open  RDA  Preliminary  Specification  (Identical  to  the  SAG's  RDA  Specification 

(6)  X/Open's  CLI  Snapshot  Specification  (Identical  to  the  SAG's  CLI  Specification) 

(7)  Open  Systems  Interconnection  (OS  I)  CCR  (Commitment,  Concurrency,  and 
Recovery):  ISO/lnternational  Electrotechnical  Commission  (IEC)  9804-3/9805-3 

(8)  OSI  Distributed  Transaction  Processing  (DTP)  Protocol:  ISO/1EC  10026  Parts  1,  2, 
and  3. 

(9)  ISO  1989:1985:  COBOL 

(10)  ANSI  X3.9-1978:  FORTRAN-77 

(11)  ANSI  X3. 159-1989:  C 

(12)  National  Institute  for  Standards  and  Technology  (NIST)  FIPS  021-3:  COBOL 

(13)  NIST  FIPS  069- 1 :  FORTRAN 

(14)  NISTFIPS  1 19,  POD  M1L-STD  1815A:  1983,  ISO 8652:  Ada _ 
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FIGURE  2.3-4  Related  standards  text  example  (cont'd.) 

(15)  _______  ~~ 

(16)  ISO/IEC  Draft  International  Standard  (DIS)  10032:  Reference  Model  of  Data 
Management 

(17)  ISO  12227  SQL/Ada  Models  Description  Language,  1994 

(18)  X3  SQLIB-1  SQL  Information  Bulletin  Number  1  Interpretation  of  ANSI  X.3.13S  - 

1989  _ 


2.3.6  Paragraph  six:  Recommendations.  "Recommendations"  advises  which  standard  is 
preferred  for  specification  in  the  procurement  for  the  particular  area  of  functionality  and 
standards.  The  recommendation  will  provide  suggested  wording  to  use  in  the  procurement  when 
possible.  Additional  guidance  about  selection  of  options  and  features  of  a  standard  is  also  included 
as  potential  solutions  to  the  portability  problems  identified  above. 

In  these  example  recommendations,  the  most  current  SQL  and  supporting  standards  are 
recommended  with  details  about  optional  conformance  levels  and  testing.  (See  Figure  2.3-5). 

FIGURE  2.3-5  Recommendations  text  example 

a.  The  following  are  related  to  data  definition,  manipulation,  query,  data  integrity,  embedded 

SQL,  and  dynamic  facilities  standards: 

(1)  Consult  the  wording  suggested  in  the  October  1991  General  Services  Agency  (GSA) 
publication  for  proposed  language  for  requiriag  that  a  database  conform  to  SQL,  and 
consult  FIPS  127-2  for  guidance  on  how  to  structure  a  Request  for  Proposal  (RFP).  The 
FIPS  "flagger"  (to  flag  nonconforming  extensions)  is  optional  and  must  be  specified 
explicitly. 

(2)  If  interactive  SQL  is  required,  a  procurement  must  indicate  explicitly  whether  or  not 
"direct  invocation  of  SQL  statements"  is  required  and,  if  required,  which  SQL  statements 
are  to  be  directly  invocable.  If  not  specified,  the  default  is  "CREATE  TABLE,"  "CREATE 
VIEW,"  "GRANT  privilege,"  "SELECT"  with  "ORDER  BY"  option,  "INSERT," 
"UPDATE:searched,"  "DELETE:searched,"  "COMMIT  WORK,"  and  "ROLLBACK 
WORK." 

(3)  Explicitly  specify  sizing  constraints  for  database  constructs.  The  FIPS  127-2  sizing 
specifications  are  reasonable  to  expect  vendors  to  deliver,  but  are  fairly  minimal.  Since 
database  construct  sizing  specifications  depend  on  the  procurement,  a  procurement  can 
override  them 

(4)  Require  the  use  of  NIST  conformance  tests  and/or  services  to  validate  conformance  to  the 
SQL-based  FIPS  for  required  and  optional  FIPS  127-2  features.  Testing  applies  only  to  a 
specific  platform,  so  call  for  conformance  tests  for  each  platform  bid.  Use  the  quarterly  list 
of  processors  validated  against  FIPS  127-2  by  NIST  to  help  evaluate  bids. 

(5)  Specify  the  NIST's  Transition  Level  SQL  2  and  the  SAG's  CLI  and  RDA  interfaces  and 
protocols  for  the  following  reasons.  Most  DBMS  vendors  have  no  intention  of  conforming 
to  the  Full  Level  SQL  2: 1992  because  it  is  very  large  and  complex.  As  a  result,  the  time  it 

_ will  take  to  add  the  necessary  features  will  probably  exceed  the  time  before  the  SQL  3 
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FIGURE  2.3-5  Recommendations  text  example 

standard  is  completed.  To  ensure  portability  as  well  as  functionality,  users  are  encouraged 
to  include  the  following  two  specifications  in  their  procurement: 

(a)  NIST's  Transition  Level  SQL  2  (specified  in  FIPS  127-2),  which  is  a  hybrid  of  Entry 
Level  and  higher  levels  of  SQL  2: 1 ">2. 

(b)  SAG's  and  X/Open's  CLI  and  RDA  standards.  The  SAG  specifications  are  not 
segmented  like  SQL  92  and  offer  a  ,„ce  balance  between  the  Full  Level  SQL  '92 
feature  set  and  what  users  need  now.  The  SAG  specifications  include  connection 
management  capabilities  (which  are  part  of  the  SQL  '93  Full  Level),  schema 
manipulation  and  the  CR/  RACTER  VARYING  data  type  (both  of  which  are  part  of 
SQL  '93  Intermediate  Level),  and  features  not  included  in  any  level  of  SQL  '92 
conformance,  including  the  CREATE  INDEX  and  DROP  INDEX  statements.  SAG's 
specifications  are  published  jointly  with  X/Open  as  X/Open  specifications. 

(6)  Specify  SQL2  (and  later  SQL3)  as  soon  as  possible  because  SQL2/3  contains  greater 
standardized  functionality  than  SQL1.  This  will  reduce  the  use  of  nonstandard  extensions. 
SQL2  also  standardizes  more  than  60  SQLCODE  exception  code  values. 

(7)  Carefully  specify  and  check  all  sizing  constraints  for  a  procurement  to  meet  functionality 
requirements  and  avoid  portability  problems. 

(8)  Avoid  the  Network  Data  Language  (NDL),  if  possible,  because  it  is  little  used  and  will  not 
be  upgraded. 

(9)  Specify  the  ISO  RDA  standard,  and  also  the  X/Open  or  SAG's  RDA  and  CLI 
specifications  in  conjunction  with  SQL/SQL2  to  obtain  remote  data  access  capabilities  in  a 
distributed  environment 

b.  The  Integrity  Constraint  feature  is  optional  in  SQL  and  must  be  specified  explicitly  for  a 

procurement.  Failure  to  do  so  means  the  Integrity  Constraint  feature  is  not  required.  Specify 

FIPS  127-2,  especially  if  any  cf  the  services  unique  to  FIPS  127-2  are  needed. 

In  SQL2,  the  integrity  enhancement  feature  is  mandatory,  not  optional.  Also,  SQL2  has  better 

integrity  constraints,  such  as  "cascade  delete  on  referential  integrity"  (in  the  intermediate  SQL 

Level)  and  "deferrable  integrity  constraints"  (in  full  SQL2). 

c.  For  embedded  SQL: 

(1)  Specify  embedded  SQL  in  an  RFF,  although  it  is  optional  in  the  standard.  Indicate  which 
programming  language  is  to  be  supported  in  references  to  embedded  SQL  in  a 
procurement.  Failure  to  do  so  means  that  support  for  any  one  FIPS  language  satisfies  the 
FIPS  SQL  requirement.  Indicate  whether  the  language  interface  is  to  support  the  Module 
Language  interface  style,  the  embedded  language  interface  style,  or  both.  Failure  to  do  so 
means  that  vendors  supporting  any  one  interface  style  satisfy  the  FIPS  SQL  requirement. 

(2)  Require  the  use  of  rsIST  conformance  tests  and/or  services  to  validate  conformance  to 
every  one  of  the  embedded  interfaces  and  module  interfaces,  and  to  validate  the  compilers 
that  will  be  used  with  the  embedded  SQL  because  SQL  testing  is  independent  of  the  host 
programming  language  testing.  Testing  applies  only  to  a  specific  platform,  so  call  for 
conformance  tests  for  each  platform  bid.  Specify  FIPS  127-2  if  any  of  the  services  unique 
to  FIPS  127-2  are  needed.  Specify  that  the  character  data  values  and  collating  sequences 
coincide  with  the  character  values  and  collating  sequence  of  the  specific  programming 
languages  to  be  used.  Failure  to  indicate  specific  character  set  requirements  means  that 

| _ support  for  representation  of  the  95-character  graphic  subset  of  American  Standard  Code 
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FIGURE  2.3-5  Recommendations  text  example 

for  Information  Interchange  (ASCQ)  (FIPS  1-2)  in  an  implementor  specified  collating 
sequence  defaults  to  the  minimum  requirement,  and  may  not  be  portable  across  other 
procured  systems. 

d.  For  dynamic  facilities,  SQL2  is  preferred.  Dynamic  SQL  is  an  intermediate  level  SQL2 
capability.  Either  SQL2's  dynamic  SQL  facilities  or  the  SQL2  intermediate  level  must  be 
specified  explicitly  in  a  procurement 

e.  For  SQL  Environments,  the  FIPS  is  applicable  in  any  situation  where  it  is  desirable  to 
Integrate  user  productivity  tools  and  heterogeneous  data  repositories  into  an  SQL 
environment  It  is  particularly  suitable  for  specifying  limited  SQL  interfaces  to  legacy 
databases  or  to  specialized  data  repositories  such  as  geographic  information  systems,  full-text 
document  management  systems,  or  object  database  management  systems. 
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2.4.  Applicable  Documents 

2.4.1  Government  documents. 

2.4. 1.1  Specifications,  standards,  and  handbooks.  The  following  specifications,  standards,  and 
handbooks  form  a  part  of  this  document  to  the  extent  specified.  Unless  otherwise  specified,  the 
issues  of  these  documents  are  those  listed  in  the  issue  of  the  DODISS  and  its  supplement.  Other 
specifications,  standards,  and  handbooks  referred  to  in  the  text  of  this  document  are  also  included 
to  the  extent  specified. 

DOD  Directive  5000.1,  Defense  Acquisition,  15  March  1996. 

DOD  Regulation  5000.2-R,  Mandatory  Procedures  for  Major  Defense  Acquisition 
Programs  (MDAPs)  and  Major  Automated  Information  System  (MAIS)  Acquisition 
Programs. 

DODD  4120.3-M,  Defense  Standardization  Program,  7  July  1993. 

2.4. 1.2  Other  government  documents,  drawings,  and  publications.  The  following  other 
government  documents,  drawings,  and  publications  form  a  part  of  this  document  to  the  extent 
specified  herein.  Other  government  documents,  drawings,  and  publications  referred  to  in  the  text 
of  this  standard  are  also  included  to  the  extent  that  this  document  specifies. 

NIST  Special  Report  500-230,  Application  Portability  Profile  (APP):  The  U.S. 
Government's  Open  System  Environment  Profile,  version  3.0,  December  1995. 

Technical  Architecture  Framework  for  Information  Management  (TAFIM),  version  3.0, 
April  30,  1996. 

DOD,  A  Framework  for  Evolution  of  the  Department  of  Defense  Intelligence  Information 
System  (DODOS),  July  1 99 1 . 

Technical  Standards  for  Command  and  Control  Information  Systems  (CCISs)  and 
Information  Technology"  by  the  Army  Tactical  Command  and  Control  Information 
System  Permanent  Working  Group,  SHAPE,  Belgium,  Edition  4, 25  February  1994. 

Office  of  Management  and  Budget  (OMB),  Federal  Participation  in  the  Development  and 
Use  of  Voluntary  Standards,  Circular  A-l  19,  Revised  October  20,  1993. 

2.4.2  Non-government  publications.  The  following  documents  form  a  part  of  this  document  to 
the  extent  specified  herein.  Unless  otherwise  specified,  the  issues  of  the  documents  adopted  by  the 
•JOD  are  listed  in  the  latest  issue  of  the  DODISS.  Unless  otherwise  specified,  the  issues  of 
documents  not  listed  in  the  DODISS  are  the  issues  of  the  documents  cited  herein. 
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IEEE  Std  1003.0-1995,  Guide  to  the  POSIX  Open  System  Environment  (OSE),  May 
1995. 

2.4.3  Standards  availability.  Unless  otherwise  indicated,  copies  of  federal  and  military 
specifications,  standards,  and  handbooks  are  available  to  DOD  activities  and  their  contractors 
from  the  Commanding  Officer,  Naval  Publications  and  Forms  Center,  (ATTN:  NPODS),  5801 
Tabor  Avenue,  Philadelphia,  PA,  19120-5099.  Others  must  request  copies  of  FIPS  from  the 
National  Technical  Information  Service,  5285  Port  Royal  Road,  Springfield,  VA,  22161-2171. 
Non-government  standards  and  other  publications  are  normally  available  from  the  organizations 
that  prepare  or  distribute  the  documents  (see  section  2.3).  These  documents  also  may  be  available 
in  or  through  libraries  or  other  informational  services. 

2.4.3.1  International  Organization  for  Standardization  (ISO)  standards.  In  the  United 
States,  ISO  standards  can  be  obtained  from  the  American  National  Standards  Institute  (ANSI,  see 
below),  which  is  the  official  United  States  representative  to  ISO.  ISO  standards  are  also  available 
directly  from  the  ISO  office: 

I  Rue  de  Varembe 
Case  Postale  56 

CH-121 1,  Geneve  20  Switzerland/Suisse 
http://www.iso.ch/ 

2.4.3.2  ANSI  standards.  ANSI  standards  are  available  from  the  American  National  Standards 
Institute  at: 

I I  West  42nd  Street 
New  York,  NY  10036 

(212)  642-4900  (telephone) 

(212)  398-0023  (fax) 

(212)  302-1246  (sales  fax) 

http://www.ansi.org/ 

2.4.3.3  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  standards.  IEEE  standards 
are  available  from  the  IEEE  Standards  Board: 

445  Hoes  Lane 
Piscataway,  NJ  08855-1331 

http://www.ieee.org/ 

2.4.3.4  Government  standards.  MIL  standards  are  available  from  local  publications  offices. 
National  Institute  of  Standards  and  Technology  (NIST)  publications  are  sold  by  the  Government 
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Printing  Office  (GPO)  and  by  the  National  Technical  Information  Service  (NTIS).  Order  numbers 
for  National  Bureau  of  Standards  (NBS)/NIST  series  numbers,  technical  notes,  or  special 
publications  may  be  obtained  from  NIST  Publications  and  Program  Inquiries  at: 

E128  Admin 
NIST 

Gaithersburg,  MD  20899 
(301)975-3058 

http://www.nist.gov/ 

Documents  then  may  be  ordered  by  order  number  from  the  GPO  at: 

Superintendent  of  Documents 
U.S.  Government  Printing  Office 
Washington,  D.C.  20402 
(202)  783-3238 

Federal  Information  Processing  Standards,  NBS/N1ST  Interagency  Reports,  and  Grant/Contract 
Reports  are  available  only  from: 

National  Technical  Information  Service  (NTIS) 

5285  Port  Royal  Road 
Springfield,  VA  22161 
(703)  487-4650  information 
(800)  336-4700  orders 

2.4.3ii  International  Telecommunication  Union  (ITU)  Telecommunications 
Standardization  Sector  (TSS)  standards.  Formerly  the  International  Telegraph  and  Telephone 
Consultative  Committee  (CCITT),  1TU-TSS  documents  can  be  obtained  from: 

ITU-TSS  General  Secretariat 
International  Telecommunications  Union 
Sales  Section 

Place  des  Nations,  Ch- 1211 
Geneve  20,  Switzerland/Suisse 

41  22  730  5111  (telephone) 

41  22  733  7256  (fax) 
http://www.itu.ch/ 

2.4.4  Order  of  precedence.  In  general,  order  of  precedence  for  DOD  applications  is  JTA 
Mandated  followed  by  JTA  Adopted  standards.  Nothing  in  this  document  supersedes  applicable 
laws  and  regulations  unless  a  specific  exemption  has  been  obtained. 
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2.5.  Information  Technology  Standards  Guidance  Reference  Model 

2.5.1  Reference  Model. 

2.5.1.1  Introduction.  This  section  of  Pait  1  of  the  1TSG  describes  a  high-level  model  for  the 
ITSG  that  will  reduce  duplication  and  assist  in  coordination.  It  includes  discussion  of  the  overall 
organization  of  the  ITSG  as  well  as  the  organization  of  information  internal  to  a  base  service  area 
(BSA). 

2.5. 1.2  Problem.  As  the  Adopted  Information  Technology  Standards  (AITS)  and  ITSG  expand 
beyond  the  limited  areas  covered  by  the  original  National  Institute  of  Standards  and  Technology 
(NIST)  Application  Portability  Profile  (APP)  and  Technical  Architecture  Framework  for 
Information  Management  (TAFIM),  a  growing  number  of  BSA's  appear  not  to  fit  into  a  specific 
area.  For  example,  is  Distributed  Database  a  Data  Management  or  Distributed  Computing  service 
area?  Is  Raster  Graphics  a  Data  Interchange  or  Graphics  service  area?  These  situations  can  lead  to 
duplication  and  the  potential  for  inconsistent  guidance.  The  proliferation  of  additional  overlapping 
service  areas,  such  as  multimedia,  visual  information,  modeling  and  simulation,  or  document 
management  will  expand  the  problem.  Defense  Infoimation  Systems  Agency  (DISA)  subject 
matter  experts  (SMBs)  are  responsible  for  coordinating  their  recommendations  with  other  related 
SMEs,  but  they  have  a  difficult  time  knowing  where  coordination  is  required  without  global 
knowledge  of  all  areas.  This  ITSG  model  will  help  reduce  duplication  and  eliminate  inconsistency, 
with  little  disruption  to  the  existing  ITSG  and  AITS  documents. 

2.5. 1.3  Current  ITSG  Model.  Historically  the  ITSG  has  used  the  Department  o i  Defense  (DOD) 
Technical  Reference  Model  (TRM)  shown  in  Figure  2.5-1  as  the  base  model.  The  ITSG  uses  the 
TRM  platform  service  areas  as  Major  Service  Areas,  each  of  which  is  divided  into  several  Mid- 
Level  Service  Areas  and  ultimately  into  many  BSAs.  These  service  areas  are  used  to  classify 
standards  for  application  programming  interfaces  (APIs)  and  external  environment  interfaces 
(EBIs).  The  ITSG  also  includes  standards  that  do  not  match  either  of  these  definitions  (e.g., 
procedural  standards).  Several  organizations  have  extended  the  DOD  TRM  to  handle  standards 
such  as  hardware  and  media  that  are  not  represented  well  in  the  current  TRM.  Discussions  are 
continuing  on  how  to  represent  the  "horizontal"  cross-area  services  such  as  security  and 
distributed  computing.  Additional  ITSG  volumes  have  been  proposed  for  areas  such  as  data 
compression.  Before  defining  additional  volumes,  the  underlying  model  should  be  reconsidered  to 
ensure  that  the  ITSG  volumes  will  provide  understandable  consistent  guidance. 
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FIGURE  2.5-1  DoD  Technical  Reference  Model 


‘Minion  Ant'  Applcadon* 


Program 
Interface  | 
(API)  | 

=L^=.l_ . . . 

- 1 

Support  ApfAkaHont 

==* 

• 

e 

MuN- 

Communi- 

BuaJnass 

Environment 

Oatebaaa 

Engl  naa  ring 

r 

1 

Meda 

cabons 

Procaaalng 

Management 

unities 

Support 

'State 

Sarvicas 

Application 

Proyam 

Interface 

(API) 


ConllQ  Control  ^ 

Part  Management  Ctonl^arw 
Fault  Management  . 

,  Uaar/Group  Mgmt  Accaw 

Usage  Managamant  / 

Othar  Mgmt  \  f 


MAJOR 

SERVICE 

AREA 

Softwara 

Enginaartng 

Sarvicas 

Uaar 

Intartaca 

Sarvicas 

Language 

Uaar  Inlerfcc' 

MID  LEVEL 

SERVICE 

AREA 

Blndlnga 

CASE 
Tools  A 
Environmant 

Graphical 

CUenl-Sarver 

Objact  Dal  A 
Managamant 

Processes 

°W 

Window 

Managamant 

Application  Platform 

Data  Data 

Managamant  Inlarchanga 


Graphics  Communications 
Sarvicas  Services 


Oata  Documant 

BSP 

Optical  Distal 
Oata  baas  Technical  Data 

M. rua.rn.nl  tVW  Applications 
Sr,l,m  RaMtr/lmao* 
Mapping 

Tranaaction  OOD  Application 
Prooaaaing  Co,T*re  salon 


Kernal  Oparatlons  Clock/Catendar  Shell  and  Utilities  K 
Raal-TIma  Extension#  Fault  Managamant  Operating  System  Object 


Network 

Services 

External 
En  viro  nman 
Interlace  (EEI) 


Human/Computer  1 
Interaction  Service! 


Information 

Interchange 


S 

1 

a 

n 

c 

t  S 

u 

•  a 

If 

*  r 
n  v 

a  I 

t 

y 

}  c 

1  a 

0  S 

s 

n 

a 

a 

r 

1 

V 

j 

i 

z 

c 

a 

a 

t 

s 

0 

n 

4" 

> 

I  ^^^*Arch  &  Apps 

I  l  Iv'C  Authenticabon 

I  V Access  Control 

integrity 

Character  Sets  A  Confidentiality 

*  p  Non-repudiation 

Cultural  Conventlona^v>||[Bhj|ny 
Natural  Language  Syatom  Mgmt 

>  Support  Security  labeling 


Related  Standards 
A  Programs.  — 


April  7,  1997 


2.5-2 


Version  3. 1 


Information  Technology  Standards  Guidance 


latroduction/Quidc 


2.5. 1.4  ITSG  Model.  The  ITSG  model  is  discussed  at  two  levels:  global  and  local.  The  global 
level  discusses  the  parts  of  die  ITSG,  while  the  local  level  discusses  the  organization  internal  to  a 
base  service  area.  At  the  global  level,  two  types  of  volumes  exist,  as  illustrated  by  Table  2.5- 1 , 
which  is  described  below.  The  ITSG  has  seven  major  service  area  volumes,  one  for  each  of  the 
TRM  major  service  areas,  as  shown  by  the  vertical  boxes  at  the  top  of  Table  2.5- 1 .  These  service 
areas  closely  correspond  to  the  service  areas  from  the  NIST  APP  and  the  Institute  of  Electrical 
and  Electronics  Engineers  (IEEE)  POSEX.O  open  systems  reference  model,  as  shown  in 
Table  2.5-2  which  describes  the  major  service  areas.  All  other  volumes  represent  cross-area 
services  and  are  composed  of  BSAs  copied  from  the  major  service  area  volumes.  These  are 
illustrated  by  horizontal  boxes  in  Table  2.5-1.  Within  Table  2.5-1,  the  entries  BSAxx  represent 
BSAs  to  show  their  usage  across  volumes.  Table  2.5-1  is  for  illustrative  purposes  only  and  does 
not  map  to  any  particular  BSA. 


T^JLB^fM^arnpie^lobalWew^n^^dodd 
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Nous:  1 .  BSAs  marked  with  t  prime  (')  ire  i  "done"  of  a  foundation  BSA. 

2.  Not  a  comprehensive  list  of  cross-area  services. 


Notes: 

1.  BSAs  marked  with  a  prime  (')  are  a  "clone"  of  a  foundation  BSA. 

2.  Not  a  comprehensive  list  of  cross-area  services. 


2.S.1.4.1  Foundation  BSA.  Each  BSA  will  be  uniquely  "grounded"  in  one  ITSG  major  service 
area.  This  BSA  is  referred  to  as  the  "foundation  BSA."  The  foundation  BSA  may  be  "cloned"  in 
other  volumes  in  a  controlled  manner,  but  the  discussion  and  recommendations  must  be  the  same 
in  each  area.  A  clone  will  consist  of  a  textual  copy  of  the  foundation  BSA  material  to  make  the 
ITSG  volumes  easier  to  use.  The  configuration  management  procedures  will  ensure  that  the 
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copies  remain  consistent.  The  SME  for  the  foundation  BSA  is  responsible  for  coordination  with 
the  SME  for  each  area  in  which  the  BSA  is  used.  A  BSA  may  be  cloned  in  another  major  service 
area  volume  if  a  BSA  is  appropriate  in  multiple  areas.  The  Raster  Graphics  BSA  mentioned  earlier 
(illustrated  by  BSAS1)  and  language  bindings  (illustrated  by  BSA31  and  BSAS1)  are  examples  of 
areas  in  which  this  is  desirable.  The  major  service  areas  are  defined  below  to  minimize  this 
duplication. 

2.5. 1.4.2  Spanning  Service  Areas.  Spanning  service  area  volumes  are  constructed  for  any 
subject  domain  that  crosses  major  service  areas.  The  classic  examples  are  system  management  and 
security  services,  but  numerous  others  have  been  proposed.  Spanning  service  areas  are  composed 
entirely  of  cloned  BS As,  as  illustrated  in  Table  2.5- 1 .  If  the  spanning  service  area  requires  a  BSA 
that  is  not  in  a  major  service  area  volume,  then  the  BSA  must  be  added  to  an  appropriate  major 
service  area.  The  spanning  area  volume  can  include  introductory  material  that  is  specific  to  the 
area.  All  BSAs  that  relate  to  the  cross-area  subject  are  copied  into  the  volume.  For  example  in 
Table  2.5-1,  BSA32,  BSA43,  BSA73,  and  BSA83  relate  to  security.  The  clone  BSA  will  contain 
the  same  recommendation  as  the  foundation  BSA.  The  spanning  service  area  SME  is  responsible 
for  coordinating  with  the  foundation  BS  A's  SME  for  each  BSA;  the  foundation  SME  is 
responsible  for  coordinating  with  all  other  SMEs  using  the  foundation  BSA.  The  configuration 
management  process,  discussed  in  a  separate  document,  will  be  used  to  resolve  any  conflicts. 

2.5.2  ITSG  Major  Service  Areas.  The  major  service  areas,  defined  to  reduce  overlap,  are  listed 
below. 

2.5.2.1  Software  Engineering  Services.  Services  that  provide  the  infrastructure  used  to  develop 
and  maintain  software,  including  general  purpose  computer  languages.  Does  not  include 
languages  specific  to  another  service  area,  such  as  user  interface  definition  languages  or  data 
retrieval  languages  (e.g.,  SQL).  Does  not  include  language  bindings,  which  are  included  with  the 
service  being  supplied  by  the  binding;  however,  these  may  be  cloned  here. 

2.5.2.2  User  Interface  Services.  Defines  methods  by  which  humans  interact  with  applications, 
regardless  of  media  (e.g.,  audio,  video).  Excludes  media-independent  formats  for  the  exchange  of 
multimedia  objects  (e.g.,  graphics  fde  formats),  which  are  included  under  Data  Interchange,  but 
may  be  cloned  here. 

2.5.2.3  Data  Management  Services.  Services  related  to  the  management  of  data  independent  of 
a  specific  application,  including  data  creation,  storage,  sharing,  retrieval,  and  manipulation,  in  a 
single-host  or  distributed  environment  Includes  languages  and  protocols  for  the  manipulation  of 
multi-media  objects,  as  well  as  all  formats  and  protocols  required  to  extend  these  services  into  a 
distributed  environment,  and  relevant  management  and  security  services. 

2.5. 2.4  Data  Interchange  Services.  Services  related  to  the  exchange  of  information,  including 
the  format  and  semantics  of  exchange  between  applications  on  the  same  or  different  platforms. 
Includes  formats  for  the  storage  and  exchange  of  multimedia  objects,  which  may  be  cloned  under 
User  Interface  or  Graphics  Services.  Does  not  include  communications  protocols  at  OSI  layer  6 
and  below. 
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2.5.2 S  Graphics  Services.  Services  related  to  die  creation  and  manipulation  of  displayed  images. 
Excludes  media-independent  formats  for  the  exchange  of  multimedia  objects  (e.g.,  graphics  file 
formats),  which  are  included  under  Data  Interchange,  but  may  be  cloned  here. 

25.2.6  Communications  and  Network  Services.  Services  required  for  data  transport  without 
regard  for  the  type  of  information.  Basically  includes  the  services  and  protocols  for  OS1  layers  6 
and  below,  plus  foundation  layer  7  services  (directory  services,  mail,  file  transfer,  remote  login). 
All  other  application  layer  services  and  protocols  will  be  included  elsewhere.  Includes  security 
services  related  to  these  base  services. 

25.2.7  Operating  System  Services.  Core  services  needed  to  operate  and  administer  the 
application  platform  and  provide  an  interface  between  the  applications  and  the  hardware  platform. 
Services  related  to  process  management,  tasking,  memory  allocation,  and  basic  file  handling.  It 
also  includes  system-wide  management  services,  such  as  accounting  and  user/group  management 
that  do  not  fit  under  any  other  service  areas.  It  includes  all  formats  and  protocols  required  to 
extend  these  core  services  into  a  distributed  environment,  as  well  as  relevant  security  services. 

Table  2.5-2  relates  the  ITSG  major  service  areas  to  service  areas  defined  in  the  NIST  Application 
Portability  Profile  and  the  IEEE  Open  Systems  Reference  Model  (POSIX.O). 

TABLE  2.5-2  ITSG  Major  Service  Areas  Related  to  NIST  APP  and  IEEE  OSE/RM 


ITSG 

Major  Service  Area 

NIST  APP 

Service  Area 

IEEE  POSIX 

OSE  Reference  Model 
Service  Area 

Software  Engineering  Services 

Software  Engineering  Services 

System  Services 

Operating  System  Services 

User  Interface  Services 

Human/Computer  Interface 

Human/Computer 

Services 

Interaction  Services 

Graphics  Services 

Graphics  Services 

Data  Management  Services 

Data  Management  Services 

Information  Services 

Data  Interchange  Services 

Data  Interchange  Services 

Communications  and  Network 

Network  Services 

Communications  and 

Services 

Network  Services 

2.5.3  Proposed  Rules.  The  following  rules  are  proposed  for  the  ITSG  reference  mode: 

(1)  The  ITSG  has  two  types  of  volumes.  There  are  seven  major  service  area  volumes, 
and  additional  (six  in  version  3.1)  spanning  service  area  volumes. 

(2)  The  ITSG  Major  Service  Areas  are  Software  Engineering  Services,  User  Interface 
Services,  Data  Management  Services,  Data  Interchange  Services,  Graphics 
Services,  Communications  and  Network  Services,  and  Operating  System  Services. 
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(3)  Each  BSA  will  be  uniquely  "grounded"  in  one  1TSG  major  service  area.  The  BSA 
will  be  grounded  in  a  "foundation  BSA."  The  BSA  may  be  "cloned"  by  reference 
or  by  copying  the  text,  although  the  latter  is  preferred. 

(4)  Cloned  BSAs  may  appear  in  more  than  one  major  service  area  volume. 

(5)  Spanning  service  area  volumes  are  composed  entirely  of  cloned  BSAs.  If  the 
spanning  service  area  requires  a  BSA  that  is  not  in  a  major  service  area  volume, 
then  the  BSA  must  be  added  to  an  appropriate  major  service  area.  The  six 
spanning  service  areas,  as  of  version  3.1)  are  System  Management,  Security, 
Distributed  Computing,  Multimedia,  Human  Factors,  and  Internationalization. 

(6)  The  cloned  BSA  will  contain  the  same  recommendation  as  the  foundation  BSA. 

(7)  The  SME  for  the  foundation  BSA  is  responsible  for  coordination  with  the  SME  for 
each  area  in  which  the  BSA  is  used. 

(8)  The  cross-area  volume  SME  is  responsible  for  coordinating  with  the  foundation 
BSA  SME  for  each  BSA. 

(9)  The  configuration  management  process  will  be  used  to  resolve  any  conflicts. 
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2.6.1  Acronyms  used  in  the  ITSG.  The  acronyms  used  in  the  ITSG  are  defined  as  follows: 

AAP  Association  of  American  Publishers 

ACG1H  American  Conference  of  Government  Industrial  Hygienists 

ACL  Access  Control  List 

ACM  Association  for  Computing  Machinery 

ACP  Allied  Communication  Publication 

ACP  Association  Control  Protocol 

ACSH  Association  Control  Service  Element 

ACVC  Ada  Compiler  Validation  Capability 

AD  Addendum  (ISO) 

AdalC  Ada  Information  Clearinghouse 

ADMAPS  Automated  Document  Management  and  Publishing  System 
ADP  Automated  Data  Processing 

ADS  Automated  Data  Systems 

ADSIA  Allied  Data  Systems  Interoperability  Agency  (NATO) 

AECMA  Association  European  des  Constructeurs  de  Material  Aerospatial 
AEP  Application  Environment  Profile 

AES  Application  Environment  Specification 

AFCEA  Armed  Forces  Communications  and  Electronics  Association 
AFS  Andrew  File  System  (CMU) 

ALAA  American  Institute  of  Aeronautics  and  Astronautics 

AIE  Ada  Integrated  Environment  (USAF) 

AIS  Automated  Information  Systems 

AUM  Association  for  Information  and  Image  Management 

AIM  Automatic  Identification  Manufacturers 

AITS  Adopted  Information  Technology  Standards 

AJPO  Ada  Joint  Program  Office  (DOD) 

ALE  Automatic  Link  Establishment 

ALS  Ada  Language  System  (U.S.  Army) 

AM  Amendment  (ISO) 

ANS  American  Nuclear  Society 

ANSI  American  National  Standards  Institute 

API  Application  Program  Interface 

APP  Application  Portability  Profile  (NIST) 

APSE  Ada  Programming  Support  Environment 

ARJDPCM  Adaptive  Recursive  Interpoiative  Differential  Pulse  Code  Modulation 
ARCAS  Army  Reserve  Component  Automation  System 
ASC  Accredited  Standards  Committee  (ANSI) 

ASCII  American  National  Code  for  Information  Interchange 
ASIS  Ada  Semantic  Interface  Specification 

ASME  American  Society  of  Mechanical  Engineers 

ASN  Abstract  Syntax  Notation 
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ASR 

ASTM 

ATA 

ATCCIS 

ATIS 

ATM 

ATMI 

AVI 

BDF 

BER 

BMP 

BOM 

BSA 

BSD 

BSFT 

BSI 

CAD 

CAE 

CAIS 

CALS 

CAM 

CASE 

CBEMA 

C3I 

CCD 

CCIS 

CCITT 

CCR 

CCS 

CCTA 

CD 

CD 

CD-I 

CD-R 

CD-ROM 

CD-V 

CD-WO 

CD-XA 

CD  IF 

CECOM 

CEDD 

CFS 


Ada  Software  Repository 

American  Society  for  Testing  and  Materials 

Air  Transport  Association  of  America 

Army  Tactical  Command  and  Control  Information  System 

A  Tool  Integration  Standard 

Automated  Teller  Machine 

Application  to  Transaction  Manager  Interface 

Audio  Video  -  Interleave 

Bitmap  Distribution  Format 
Basic  Encoding  Rules  (ASN) 

Windows  Bitmap  Format  (Microsoft) 

Bit-Oriented  Messages 
Base  Service  Area 
Berkeley  Software  Distribution 
Byte  Stream  File  Transfer 
British  Standards  Institute  (UK) 

Computer-Aided  Design 
Common  Application  Environment 

Common  Ada  Programming  Support  Environment  (APSE)  Interface  Set 

Computer-Aided  Acquisition  and  Logistic  Support 

Computer-Aided  Manufacturing 

Computer  Aided  Software  Engineering 

Computer  and  Business  Equipment  Manufacturers  Association 

Command,  Control,  Communications,  and  Intelligence 

Charge  Coupled  Devices 

Command  and  Control  Information  System 

Comite  Consultatif  International  de  Telegraphique  et  Telephonique  (International 
Telegraph  and  Telephone  Consultative  Committee)  (now  called  the  ITU-TSS) 
Commitment,  Concurrency,  and  Recovery 
Continuous  Composite  Servo 

Central  Computer  and  Telecommunication  Agency  (UK) 

Committee  Draft  (ISO) 

Compact  Disc 

Compact  Disc  -  Interactive 

Compact  Disc  -  Recordable 

Compact  Disc  -  Read  Only  Memory 

Compact  Disc  -  Video 

Compact  Disc  -  Write  Once 

Compact  Disc  -  Extended  Architecture 

CASE  Data  Interchange  Format 

Communications-Electronics  Command  (U.S.  Army) 

Committee  for  the  Exchange  of  Digital  Data  (IHO) 

Center  for  Standards  (DISA/JIEO) 
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CGI  Computer  Graphics  Interface 

CGM  Computer  Graphics  Metafile 

CIA  Central  Intelligence  Agency 

CID  Commercial  Item  Description 

CIE  Comite  International  de  lBclairage  (International  Commission  on  Illumination) 

CIM  Center  for  Information  Management  (DISA) 

CINC  Commander  in  Chief 

CIS  CASE  Integration  Services 

CICS  Chairman  of  the  Joint  Chiefs  of  Staff 

CLNS  Common  LISP  Object  System 

CM  Communication  Manager 

CMA  Consolidated  Management  Architecture 

CM-API  Consolidated  Management  API 

CMIP  Common  Management  Information  Protocol 

CMIS  Common  Management  Information  Services 

CMOT  CMIP  Over  TCP/IP 

CMU  Carnegie  Mellon  University 

CMW  Compartmented  Mode  Workstation 

CMYK  Cyan,  Magenta,  Yellow,  and  Black 

COE  Common  Operating  Environment 

COEWG  Common  Operating  Environment  Working  Group 

COMPUSEC  Computer  Security 

CONS  Connection  Oriented  Network  Service 

CORBA  Common  Object  Management  Request  Broker  Architecture 

COTS  Commercial  Off-the-Shelf 

CPC  Consortia  Public  Consensus 

CPC  Cross-Platform  Communications  (IMA) 

CPSC  Consumer  Product  Safety  Commission 

CRSS  C3I  Reusable  Software  System 

csh  C  Shell 

CTE  Compound  Text  Encoding 

CUA  Common  User  Access 

DAC  Discretionary  Access  Controls 

DAD  Draft  Addendum  (ISO) 

DAM  Draft  Amendment  (ISO) 

DAP  Document  Application  Profile 

DARPA  Defense  Advanced  Research  Program  Agency 

DBF  Discrete  Block  Format 

DBMS  Database  Management  System 

DBSSF  Database  System  Study  Group 

DCA  Document  Content  Architecture 

DCE  Distributed  Computing  Environment 

DCPS  Data  Communications  Protocol  Standards 

DCW  Digital  Chart  of  the  World  (DMA) 
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DDE 

Dynamic  Data  Exchange 

DDES 

Digital  Data  Exchange  Specification 

DDF 

Data  Descriptive  File  (for  Information  Interchange) 

DDRS 

Data  Dictionary/Repository  System 

DEA 

Data  Encryption  Algorithm 

DEC 

Digital  Equipment  Corporation 

DER 

Distinguished  Encoding  Rules  (BER/ASN) 

DES 

Data  Encryption  Standard 

DFR 

Document  File  and  Retrieval 

DFS 

Distributed  File  System 

DGIWG 

Digital  Geographic  Information  Working  Group 

DIA 

Defense  Intelligence  Agency 

DIA 

Display  Industry  Association 

DIA 

Document  Interchange  Architecture 

DIB 

Directory  Information  Base 

DID 

Data  Item  Description 

DIF 

Data  Interchange  Format 

DIGEST 

Digital  Geographic  Information  Exchange  Standard 

DIS 

Draft  International  Standard  (ISO) 

DISA 

Defense  Information  Systems  Agency  (DOD) 

DFR 

Document  Filing  and  Retrieval 

DFS 

Distributed  File  System 

DMA 

Defense  Mapping  Agency  (DOD) 

DME 

Distributed  Management  Environment 

DMI 

Definition  of  Management  Information 

DNI 

Detailed  Network  Interface 

DNS 

Domain  Naming  Service 

DOAM 

Distributed  Office  Applications  Model 

DOD 

Department  of  Defense 

DODIIS 

DOD  Intelligence  Information  System 

DODISS 

DOD  Index  of  Specifications  and  Standards 

DOS 

Disk  Operating  System 

DOT 

Department  of  Transportation 

DP 

Draft  Proposed  Standard  (ANSI,  ISO) 

DPA 

Document  Printing  Application 

DPS 

Digital  Production  System  (DMA) 

DSRS 

Defense  Software  Repository  System 

DSS 

Digital  Signature  Standard 

DSSC 

Distributed  Systems  Steering  Committee  (IEEE) 

DSSSL 

Document  Style  Segmentation  and  Specification  Language 

DTAM 

Document  Transfer  and  Manipulation 

DTMP 

DCPS  Technical  Management  Panel 

DTP 

Distributed  Transaction  Processing 

DVI 

Digital  Video  Interactive 

DWM 

Desqview  Window  Manager 
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DXF  Drawing  Exchange  Format  (Autodesk) 

EAN  International  Article  Numbering  Association 

ECMA  European  Computer  Manufacturers'  Association 

EDI  Electronic  Document  Interchange 

EDIF  Electronic  Data  Interchange  Format 

EDIT  ACT  EDI  for  Administration,  Commerce,  and  Transport 

EEC  European  Economic  Community 

EEI  External  Environment  Interface 

El  A  Electronic  Industries  Association 

EMPM  Electronic  Manuscript  Preparation  and  Markup 

EPA  Environmental  Protection  Agency 

EPHOS  European  Procurement  Handbook  for  Open  Systems 

ES-IS  End  System  to  Intermediate  System 

EWOS  European  Workshop  for  Open  Systems 

FAA  Federal  Aviation  Administration 

FAP  Formats  and  Protocols  (SQL) 

FDDI  Fiber  Distributed  Data  Interface 

4GL  Fourth  Generation  Language 

FIMS  Form  Interface  Management  System 

FIPS  Federal  Information  Processing  Standard  (NIST) 

FIPS  PUB  Federal  Information  Processing  Standard  Publication 

FM  Field  Manual 

FTAM  File  Transfer,  Access,  and  Management 

FTP  File  Transfer  Protocol  (Internet) 

FY  Fiscal  Year 

GDMO  Guidelines  for  the  Definition  of  Managed  Objects 

GDSII  Graphic  Design  System  II 

GIF  Graphics  Interchange  Format 

GIS  Geographic  Information  System 

GKS  Graphical  Kernel  System 

GKS-3D  Graphical  Kernel  System  for  Three  Dimensions 

GMI  Generic  Management  Information 

GNMP  Government  Network  Management  Profile 

GOSIP  Government  Open  Systems  Interconnection  Profile 

GOTS  Government  Off-the-Shelf 

GPC  Government  Public  Consensus 

GPC  Graphics  Performance  Characterization  Committee 

GPEF  Generic  Package  of  Elementary  Functions 

GPO  Government  Printing  Office 

GPPF  Generic  Package  of  Primitive  Functions 

GRACE  Generic  Reusable  Ada  Components  for  Engineering 

GUI  Graphical  User  Interface 
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GULS 


Generic  Upper  Layer  Security 


HCI  Human-Computer  Interface 

HDL  Hardware  Description  Language 

HDLC  High-Level  Data  Link  Control 

HDTV  High  Definition  Television 

HF  High  Frequency 

HFS  Human  Factors  Society 

HLHSR  Hidden  Line/Hidden  Surface  Removal 

HOL  High  Order  Language 

HP  Hewlett  Packard 

HPDL  Hewlett-Packard  Page  Description  Language 

HYT1ME  Hypermedia/Time-based  Structuring  Language 

IAB  Internet  Architecture  Board 

IBM  International  Business  Machines  Corporation 

ICAM  Integrated  Computer-Aided  Manufacturing 

ICASE  Integrated  Computer-Aided  Software  Engineering 

ICC  International  Color  Consortium 

ICCCM  Interclient  Communications  Conventions  Manual 

ICCD  Integrated  Charge  Coupled  Devices 

ICR  Intelligent  Character  Recognition 

IDEF  Integrated  Definition 

IDEF  ICAM  Definition  Language 

IDHS  Intelligence  Data  Handling  System 

IDL  Interface  Definition  Language 

IDT  Interactive  Design  Tools 

IDTIF  Interactive  Design  Tool  Interchange  Format 

IEC  International  Electrotechnical  Commission 

IEEE  Institute  of  Electrical  and  Electronics  Engineers 

IETF  Internet  Engineering  Task  Force 

I4DL  Interface,  Inheritance,  Implementation,  and  Instantiation  Definition  Language 

IFF  Interchange  File  Format 

IGES  Initial  Graphics  Exchange  Specification 

IHO  International  Hydrographic  Organization 

IM  Information  Management 

!MA  Interactive  Multimedia  Association 

IMA  International  MIDI  Association 

I/O  Input/Output 

IOH  Integrated  Open  Hypermedia 

IP  Information  Processing 

IPC  International  Public  Consensus 

IPC  Interprocess  Communications 

IPO  IGES/PDES  Organization 

IPSC  Information  Processing  Standards  for  Computers 
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IR 

IRDS 

IS 

ISAM 

ISDN 

ISEE 

IS-IS 

ISO 

IT 

ITPB 

ITSEC 

rrsG 

ITU 

ITU-R 

ITU-TSS 


JBIG 

JCALS 

JIEO 

JPEG 

JTA 

JTC1 

KBPS 

KMP 

LAN 

LM 

LMS 

LS 

LSA 

LSAR 

LWER 

LZW 

MAC 

MAC 

MAC 

MAP 

MB 

MCCR 

MHEG 

MHS 

MHz 


Interim  Report 

Information  Resource  Dictionary  System 
International  Standard  (ISO) 

Indexed  Sequential  Access  Method 
Integrated  Services  Digital  Network 
Integrated  Software  Engineering  Environment 
intermediate  System  to  Intermediate  System 
International  Organization  for  Standardization 
Information  Technology 
Information  Technology  Policy  Board  (DOD) 

Information  Technology  Security  Evaluation  Criteria 
Information  Technology  Standards  Guidance 
International  Telecommunications  Union 

International  Telecommunications  Union  -  Radiography  (formerly  the  CCIR) 
International  Telecommunications  Union  -  Telecommunications  Standardization 
Sector  (formerly  the  CCITT) 

Joint  Bi-Level  Imaging  Group 

Joint  Computer-Aided  Acquisition  and  Logistic  Support 

Joint  Interoperability  Engineering  Organization 

Joint  Photographic  Experts  Group 

Joint  Technical  Architecture 

Joint  Technical  Committee  One  (ISO/1EC) 

Kilobytes  per  Second 
Key  Management  Protocol 

Local  Area  Network 

License  Management 

Logistics  Management  System 

License  Management  System 

Logistic  Support  Analysis 

Logistic  Support  Analysis  Records 

Light  Weight  Encoding  Rules  (BER/ASN) 

Lempe!-Ziv- Welsh  (data  compression  algorithm) 

Mandatory  Access  Controls 
Media  Access  Control 
Message  Authentication  Code 
Manufacturing  Automation  Protocol 
Megabyte 

Mission  Critical  Computer  Resources 
Multimedia/Hypermedia  Experts  Group 
Message  Handling  System 
Megahertz 
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MIB 

Management  Information  Base 

MICR 

Magnetic  Ink  Character  Recognition 

MIDI 

Musical  Instrument  Digital  Interface 

MIL-STD 

Military  Standard 

MIS 

Management  Information  System 

MIT 

Massachusetts  Institute  of  Technology 

MMFS 

Manufacturing  Message  Format  Standard 

MMI 

Man-Machine  Interface 

MMS 

Manufacturing  Message  Standard 

MO 

Magneto-Optical 

MO:DCA 

Mixed  Object  Document  Content  Architecture  (IBM) 

MOOLIT 

Motif/Open  Look  Toolkit  Intrinsics 

MOTIS 

Message  Oriented  Text  Interchange  System 

MOSS 

Map  Overlay  Statistical  System  (Autometric) 

MPC 

Multimedia  Personal  Computer 

MPEG 

Motion  Pictures  Expert  Group 

MS 

Microsoft 

MSP 

Message  Security  Protocol 

MTA 

Message  Transfer  Agent 

MTF 

Message  Text  Formats 

MTF 

Message  Transfer  Facility 

MUI 

Management  User  Interface 

MVL 

Multivalue  Logic  System 

MWM 

Motif  Window  Manager 

NAPLPS 

North  American  Presentation  Level  Protocol  Syntax 

NASA 

National  Aeronautics  and  Space  Administration 

NATO 

North  Atlantic  Treaty  Organization 

NBS 

National  Bureau  of  Standards  (now  NIST) 

NBSERNBS 

Interim  Report 

NCGA 

National  Computer  Graphics  Association 

NCSC 

National  Computer  Security  Center 

NCSL 

National  Computer  Systems  Laboratory  (NIST) 

NDL 

Network  Data  Language 

NeL 

Network  Event  Logger 

NetLS 

Network  License  System 

NFS 

Network  File  System 

NGCR 

Next  Generation  Computer  Resources 

NGS 

Non-Government  Standards 

NGSB 

Non-Government  Standards  Body 

NIMA 

National  Imagery  and  Mapping  Agency  (formerly  DMA) 

NISO 

National  Information  Standards  Organization 

NIST 

National  Institute  of  Standards  and  Technology 

NISTIR 

NIST  Interim  Report 

NITF 

National  Imagery  Transmission  Format 
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NITFS 

National  Imagery  Transmission  Format  Standard 

NIUF 

National  ISDN  Users'  Forum 

NIUG 

National  IGES  User's  Group 

NLSP 

Network  Layer  Security  Protocol 

NMF 

Network  Management  Forum 

NMSIG 

Network  Management  SIG 

NPC 

National  Public  Consensus 

NPESA 

National  Printing  Equipment  and  apply  Association 

NSA 

National  Security  Agency 

NSC 

National  Safety  Council 

NSEP 

National  Security  Emergency  Preparedness 

NSI 

Non-Standard  Interface 

NT 

New  Technology  (MS-Windows) 

NTF 

National  Transfer  Format  (BSI) 

NTIS 

National  Technical  Information  Service 

NTSC 

National  Television  System  Committee  (US) 

OCR 

Optical  Character  Recognition 

OCR-MA 

Optical  Character  Recognition-  Matrix 

ODA 

Office  Document  Architecture 

ODJF 

Office  Document  Interchange  Format 

ODL 

Office  Document  Language 

ODMG 

Open  Database  Management  Group 

ODP 

Open  Distributed  Processing 

ODT 

Optical  Digital  Technologies 

orM 

Object  Information  Management 

OIW 

OSE  Implementors'  Workshop  (NIST) 

OLE 

Object  Linking  and  Embedding 

OLIT 

Open  Look  Intrinsics  Toolkit 

OLTP 

Online  Transaction  Processing 

OLWM 

Open  Look  Window  Manager 

OMG 

Object  Management  Group 

ONC 

Open  Network  Computing 

OSD 

Office  of  the  Secretary  of  Defense 

OSE 

Open  System  Environment 

OSF 

Open  Software  Foundation 

OSHA 

Office  of  Safety  and  Health  Administration 

OSI 

Open  Systems  Interconnection  (ISO) 

PAL 

Phase  Alternation  Line 

PAR 

Project  Authorization  Request  (IEEE) 

PART 

POSIX/Ada  Real-Time  project 

PBX 

Private  Branch  Exchange 

PC 

Personal  Computer 

PCF 

Portable  Compiled  Format 
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PCIS 

PCMCIA 

PC/NFS 

PCTE 

P  D  AD 

PD  AM 

PDDI 

PDES 

PDI 

PDL 

PEL 

PER 

PERMS 

PEX 

PHIGS 

PHIGS+ 

PICS 

PIF 

PIK 

PLPS 

PLUS 

PM 

POSIX 

PRC 

RAPID 

RDA 

RFC 

RFP 

RFS 

RGB 

RLE 

RODE 

ROP 

ROSE 

ROSEP 

ROSES 

RPC 

RRIP 

RSA 

RTCP 

RTSE 

SAA 


Portable  Common  Interface  Set  (NATO) 

Personal  Computer  Memory  Card  Industry  Association 
Personal  Computer/Network  File  System 
Portable  Common  Tools  Environment  (ECMA) 

Preliminary  Draft  Addendum  (ISO) 

Preliminary  Draft  Amendment  (ISO) 

Product  Data  Definition  Interface 
Product  Data  Exchange  Using  STEP 
Picture  Description  Language 
Page  Description  Language 
Picture  Element 

Packed  Encoding  Rules  (BER/ASN) 

Personnel  Electronic  Records  Management 
PHIGS  Extension  to  X 

Programmer's  Hierarchical  Interactive  Graphics  System 

Programmer's  Hierarchical  Interactive  Graphics  System  Plus  Lumier  and  Surfaces 

(PLUS) 

Protocol  Implementation  Conformance  Statement 
Page  Image  Format 
Programmer's  Imaging  Kernel 
Presentation  Level  Protocol  Syntax 
Plus  Lumier  und  Surfaces  (see  PHIGS) 

Program  Manager 

Portable  Operating  System  Interface  for  Computer  Environments 
Planning  Research  Corporation 

Reusable  Ada  Products  for  Information  Systems  Development 

Remote  Database  Access 

Request  for  Comment 

Request  for  Proposal 

Remote  File  System 

Red,  Green,  Blue 

Run  Length  Encoding 

Remote  Open  Document  Editing 

Remote  Operations  Protocol 

Remote  Operations  Service  Elements 

Remote  Operations  Service  Elements  Protocol  Definition 

Remote  Operations  Service  Elements  Service  Definition 

Remote  Procedure  Call 

Rock  Ridge  Interchange  Protocol 

Rivest-Shamir-Adelman 

Real-Time  Communication  Protocols 

Reliable  Transfer  Service  Element 

Systems  Application  Architecture 
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SAE 

SAG 

SAME 

SAMEDL 

SBIS 

sees 

SCD 

SCO 

SDD 

SDF 

SDIF 

SDNS 

SDO 

SDTS 

SDU 

SECAM 

SEE 

SEI 

SE-ODP 

SGML 

SIF 

SIG 

SIGADA 

SIGGRAPH 

SII 

SSLS 

SMDL 

SMB 

SMD 

SME 

SME 

SMI 

SMIGS 

SMP 

SMPTE 

SMTP 

SNA 

SNDCF 

SNF 

SNI 

SNMP 

SP 

SP 

SP 

SPC 


Society  of  Automotive  Engineers 

SQL  Access  Group 

SQL  Ada  Module  Extensions 

SAME  Description  Language 

Sustaining  Base  Information  System 

Source  Code  Control  System 

Stock  Control  and  Distribution  (SYSTEM) 

Santa  Cruz  Operation 

Software  Design  Document 

Standard  Delay  File  Format 

SGML  Document  Interchange  Format 

Secure  Data  Network  Systems 

Standards  Developing  Organization 

Spatial  Data  Transfer  Standard 

Software  Development  Utilities 

Systeme  Electonique  Couleur  Avec  Memoire 

System  Engineering  Environment 

Software  Engineering  Institute 

Support  Environment  for  Open  Distributed  Processing 

Standard  Generalized  Markup  Language 

Standard  Interchange  Format  (Intergraph) 

Special  Interest  Group 

Ada  Special  Interest  Group  (ACM) 

Graphics  Special  Interest  Group  (ACM) 

System  Internal  Interface 

Standard  for  Interoperable  LAN  Security 

Standard  Music  Description  Language 

Server  Message  Block 

Standardized  Military  Drawing 

Society  of  Manufacturing  Engineers 

Subject  Matter  Expert 

Structure  of  Management  Information 

Standard  Military  Graphics  Symbols 

Simple  Management  Protocol 

Society  of  Motion  Picture  and  Television  Engineers 

Simple  Mail  Transfer  Protocol 

Systems  Network  Architecture 

Subnetwork  Dependent  Convergence  Facility 

Server  Normal  Format 

Simple  Network  Interface 

Simple  Network  Management  Protocol 

Security  Protocol 

Special  Publication  (NIST) 

Standardization  Profile 
Software  Productivity  Consortium 
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SPDL  Standard  Page  Description  Language 

SPI  System  Programming  Interface 

SPM  Software  Programmer's  Manual 

SQL  Structured  Query  Language 

SS  Sampled  Servo 

SSC  Standards  Systems  Center 

STANAG  Standardization  Agreement  (NATO) 

STARS  Software  Technology  for  Adaptable,  Reliable  Systems 
STD  Standard 

STDL  Standardized  Transaction  Definition  Language 

STL  Standard  Textual  Language 

STEP  Standard  for  Exchange  of  Product  Model  Data 

SUSP  System  Use  Sharing  Protocol 

SVID  System  V  Interface  Definition 

SVRn  System  V  Release  n  (USL) 

TACO-2  Tactical  Communication  Protocol  2 

TADIL  Tactical  Digital  Information  Link 

TAE  Transportable  Application  Environment 

TAE+  Transportable  Application  Environment  Plus 

TAR  UNIX  Transfer  Tape  Format 

TBD  To  Be  Determined 

TCL  TAE  Command  Language 

TCOS  Technical  Committee  on  Operating  Systems  (IEEE) 

TCP/IP  Transmission  Control  Protocol/lntemet  Protocol 

TCSEC  Trusted  Computer  Systems  Evaluation  Criteria 

TDI  Trusted  Database  Interpretation 

TEI  Text  Encoding  Initiative 

TFA  Transparent  File  Access 

TFTP  Trivial  File  Transfer  Protocol 

TGA  Targa  Image  Format 

TIFF  Tagged  Image  File  Format 

TIGER  Topographically  Integrated  Geographical  Encoding  and  Referencing  (U.S.  Census 
Bureau) 

TLI  Transport  Layer  Interface 

TLSP  Transport  Layer  Security  Protocol 

TNI  Trusted  Network  Interpretation 

TNT  The  News  Toolkit 

TOP  Technical  and  Office  Protocol 

TOSCA  Text  and  Office  Systems  Color  Architecture  (ISO) 

TP  Transaction  Processing 

TR  Technical  Report 

TRIF  Tiled  Raster  Interchange  Format  (DOD) 

TS  Timer  Services 

TSR  Terminate  and  Stay  Resident 
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TSS 

Telecommunications  Standardization  Sector  (ITU) 

UCC 

Uniform  Code  Council 

UDT 

Unstructured  Data  Transfer 

UEF 

User  Exchange  Format 

UFS 

Unix  File  System 

Ul 

Unix  International 

UJDL 

User  Interface  Definition  Language 

UIL 

User  Interface  Language  (OSF) 

UIMS 

User  Interface  Management  Services 

UISRM 

User  Interface  System  Reference  Model  (NIST) 

UK 

United  Kingdom 

UPC 

Uniform  Product  Code 

USGS 

United  States  Geological  Survey 

USL 

Unix  Systems  Labs 

USMTF 

United  States  Message  Text  Format 

USS 

Uniform  Symbology  Specification 

UUCP 

Unix-to-Unix  Copy  Protocol 

VDI 

Virtual  Device  Interface 

VDM 

Virtual  Device  Metafile 

VDT 

Video  Display  Terminal 

VHDL 

VHSIC  Hardware  Description  Language 

VMF 

Variable  Message  Format 

VMUIF 

Voice  Messaging  User  Interface  Forum 

VOXEL 

Volume  Element 

VPF 

Vector  Product  Format 

VPS 

Vector  Product  Standard 

VQ 

Vector  Quantization 

VT 

Virtual  Terminal 

WAN 

Wide-Area  Network 

WD 

Working  Draft  (ISO) 

WDAD 

Working  Draft  Addendum  (ISO) 

WDAM 

Working  Draft  Amendment  (ISO) 

WG 

Working  Group 

WMO 

World  Meterological  Organization 

WORM 

Write-Once  Read  Many 

WWMCCS 

World-Wide  Military  Command  and  Control  System 

WYSIWYG 

What  You  See  Is  What  You  Get 

XaPIA 

X.400  API  Association 

XAP-TP 

X/Open  API-  Transaction  Processing 

XCDR 

X/Open  CD  ROM 

XDR 

External  Data  Representation 

XDS 

X/Open  Directory  Services 
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XDSF 

XllRn 

XLFD 

XMOG 

XMP 

XMPP 

XNFS 

XOM 

XPG 

XTI 

XVT 


X/Open  Distributed  Security  Framework 
X  Windows  version  1 1,  Release  n 
X  Logical  Font  Description 
X/Open  Managed  Object  Guide 
X/Open  Management  Protocol 
X/Open  Management  Protocol  Profiles 
X/Open  Network  File  System 
X/Open  OSI  Abstract  Data  Manipulation 
X/Open  Portability  Guide 
Transport  Independent  Interface 
Extensible  Virtual  Toolkit 
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2.6.2  Terms  used  in  the  ITSG.  The  following  definitions  align  as  closely  as  possible  to  the 
standard  IEEE  Computer  Society  definitions  and  come  from  a  myriad  of  standards  bodies.  Be 
careful  to  understand  the  terms  commonly  used  inside  and  outside  this  document  Different 
standards  bodies  often  use  different  words  for  the  same  meaning  or  may  use  the  same  word  with 
an  assumption  of  a  slightly  different  meaning.  For  example,  the  American  National  Standards 
Institute  (ANSI)  used  the  term  "levels"  (meaning  "level  1,"  "level  2,"  and  "Core")  to  signal  a 
particular  implementation's  varying  conformance  level;  however,  this  usage  is  parallel  to  the  IEEE 
POSDOs  usage  of  "fully  conforming"  and  "conforming  with  extensions." 

Abstraction:  An  abstraction  denotes  the  essential  characteristics  of  an  object  that  distinguish  it 
from  all  other  lands  of  objects,  providing  crisply  defined  conceptual  boundaries,  relative  to  the 
perspective  of  the  viewer.  (See  Object-Based  and  Object-Oriented  Language). 

Accredited  Standards  Development  Organization:  An  organization  recognized  as  a  standards 
development  organization  by  ISO,  IEC,  ITU-T,  or  recognized  as  a  standards  development 
organization  by  one  of  the  member  bodies  of  one  of  these  three  organizations. 

Adopted:  The  DOD  status  “Adopted"  is  used  to  mean  that  the  standard  in  the  ITSG  is  approved 
by  DOD  for  use  in  satisfying  each  function  of  the  BSA  where  there  exists  no  JTA  mandated 
standard.  Adopted  standards  may  be  implemented  but  shall  not  be  used  in  lieu  of  a  mandated 
standard.  The  word  adopted  refers  to  standards  included  in  the  TAFIM. 

Application:  "The  use  of  capabilities  provided  by  an  information  system  specific  to  the 
satisfaction  of  a  set  of  user  requirements."  (IEEE  Std  1003.0-1995) 

Application  Environment  Profile  (AEP):  "A  profile,  specifying  a  completed  and  coherent 
specification  of  the  Open  System  Environment  (OSE),  in  which  the  standards,  options,  and 
parameters  chosen  are  necessary  to  support  a  class  of  applications."  (IEEE  Std  1003.0-1995) 

Application  Platform:  "A  set  of  resources,  including  hardware  and  software,  that  support  the 
services  on  which  application  software  will  run.  The  application  platform  provides  services  at  its 
interfaces  that,  as  much  as  possible,  make  the  specific  characteristics  of  the  platform  transparent 
to  the  application  software."  (IEEE  Std  1003.0- 1995) 

Application  Program  Interface  (API):  "The  interface  between  the  application  software  and  the 
application  platform,  across  which  all  services  are  provided."  (IEEE  Std  1003.0-1995) 

Application  Software:  "Software  that  is  specific  to  an  application  and  is  composed  of  programs, 
data,  and  documentation  (IEEE  Std  1003.0-1995) 

Approved:  The  specification  has  been  approved  and  published  by  its  sponsoring  body. 

Base  Service  Areas  (BSAs):  define  functionality  within  the  OSE.  They  also  serve  as  logical 
placeholder  for  groupings  of  standards  that  share  similar  attributes  of  functionality.  Each  BSA 
contains  a  definition,  approximated  to  the  collection  of  standards  contained  within  it.  Each  BSA 
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parallels  an  industry  accepted  information  technology  "functional"  area  at  a  broad  system  service 
level.  BSA  definitions  serve  to  map  functional  system  support  software  requirements  to  specific 
standards  through  matching  the  BSA  definition  to  the  standards  within.  BSA  definitions  are 
tailored  for  human  comprehension,  not  to  meet  a  requirement  for  technical  formalism  of  the  OSE. 

Base  Standard:  "An  approved  international  standard,  technical  report,  ITU-T  Recommendation, 
or  national  standard."  (IEEE  Std  1003.0-199S) 

Base  Standard  Profile:  A  profile,  or  listing,  of  applicable  base  standards.  (See  Profile  of 
Standards.) 

Class:  A  set  of  objects  with  a  common  structure  and  behavior. 

Communication  Interface:  "That  part  of  the  API  devoted  to  communications  with  other 
application  software,  external  data  transport  facilities,  and  devices."  (IEEE  Std  1003.0-1995) 

Component  Profile:  "A  profile  that  is  made  up  of  a  formally  defined  subset  of  a  single  standard." 
(IEEE  Std  1003.0-1995) 

Conditional  feature:  A  feature  or  behavior  referred  to  in  a  standard  not  essential  on  all 
conforming  implementations. 

Conformance:  "A  statement  of  conformance  to  a  POSIX  standard  is  based  on  a  completed  test 
of  the  target  system  using  POSIX.3  conforming  test  methods,  where  for  each  POS1X.3  assertion 
for  that  standard,  there  is  a  correctly  assigned  test  result  code."  (IEEE  Std  1003.3-1991) 

Conformance  Documentation:  "A  formal  record  of  the  testing  of  a  product  for  conformance  to 
a  particular  standard."  (ISO/IEC  9945-1 ) 

Consortia  (Standards):  Standards  developed  by  industry  associations,  consortia,  and  other 
public  bodies  not  recognized  as  formal  standards  bodies. 

Criteria  for  Inclusion:  Qualities  considered  to  determine  whether  a  standard  will  be  included. 

Cross-Category  Services:  "A  set  of  tools  and/or  features  that  has  a  direct  effect  on  the 
operation  of  one  or  more  components  of  the  OSE,  but  is  not  in  and  of  itself  a  stand-alone 
component."  (IEEE  Std  1003.0- 1 995) 

De  facto:  Indicating  the  use  of  the  product  or  specification  in  reality  that  is  tantamount  to  being 
legally  constituted  as  a  standard. 

De  jure:  Indicating  that  a  specification  has  undergone  the  standardization  process  of  a  formal 
standards  body. 

Deficiency:  A  functionality  needed,  but  not  provided,  by  the  standard. 
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Dependency:  One  standard  requiring  the  support  of  other  standards  to  create  a  valid 
implementation. 

Detailed  Profile:  see  Standard  Profile. 

Distributed  (System,  Processing):  A  system  or  process  consisting  of  interdependent  software 
or  hardware/software  entities  separated  either  physically  or  chronologically. 

Emerging  Standard:  According  to  the  JTA,  a  OOD  "Emerging"  status  denotes  a  candidate 
standard  to  be  added  as,  or  to  replace,  a  mandated  standard.  This  includes  standards  required  to 
capitalize  on  new  technologies.  These  candidates  will  help  the  program  manager  determine  those 
areas  that  are  likely  to  change  in  the  near  term  (within  three  years)  and  suggest  those  areas  in 
which  "upgradability"  should  be  a  concern.  The  expectation  is  that  emerging  standards  will  be 
elevated  to  mandated  status  in  the  JTA  when  implementations  of  the  standards  mature.  Emerging 
standards  may  be  implemented  but  si  *!!  not  be  used  in  lieu  of  a  mandated  standard. 

Encapsulation:  The  process  of  h.dinjuii  ««•»..•  dvt.,.!s  of  an  object  that  do  not  contribute  to  its 
essential  characteristics.  (See  Object- Based  and  Object  .  .--.v  1  .anguage). 

Explicit  Services:  "Services  that  can  be  accessed  from  an  application  program  (via  an  API)  and 
generally  are  only  provided  when  requested."  (IEEE  Stri  1003.0-1995) 

External  Environment:  "A  set  of  entities  external  to  the  application  platform  with  which 
services  are  provided.  External  entities  include  people,  exchangeable  media  that  is  not  mounted  in 
the  platform,  communication  wiring,  and  other  platforms."  (IEEE  Std  1003.0-1995). 

External  Environment  Interface  (EEI):  "The  interface  between  the  application  platform  and 
the  external  environment  across  which  services  are  provided.  The  EEI  is  defined  primarily  in 
support  of  system  and  application  interoperability.  The  primary  services  present  at  the  EEI 
comprise: 

a.  Human/Computer  Interaction  Services 

b.  Information  Services 

c.  Communication  Sendees"  (IEEE  Std  1003.0-1995) 

Extension:  An  addition  to  the  core  specifications  of  a  standard. 

Formal  Standards  Body:  "Formally  recognized  standards  bodies  responsible  for  definition  and 
dissemination  of  public  standards."  (IEEE  Std  1003.0-1995) 

Hardware:  "Physical  equipment  used  in  data  processing,  as  opposed  to  programs,  procedures, 
rules,  and  associated  documentation.”  (IEEE  Std  1003.0-1995). 

Harmonization:  "The  process  of  ensuring  that  profiles  do  not  overlap  or  conflict."  (IEEE  Std 
1003.0-1995). 
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Hierarchy:  A  ranking  or  ordering  of  abstractions.  (See  Object-Based  and  Object-Oriented 
Language). 

Hostile  Standard  Feature:  Any  feature  of  a  standard  that  could  impede  transportability  or 
requires  additio  cost  to  transport 

Human/Computer  Interface  (HCI):  "The  boundary  across  which  physical  interaction  between 
a  human  being  and  the  application  platform  takes  place."  (IEEE  Std  1003.0-1995). 

Implementation  Defined:  "An  indication  that  the  implementation  shall  define  and  document  the 
requirements  for  correct  program  constructs  and  correct  data  of  a  value  or  behavior."  (ISO/IEC 
9945-1) 

Implementation  Dependent:  Indicates  that  each  implementor  may  define  that  portion  of  the 
application  at  will. 

Implicit  Services:  "Services  that  the  platform  provides  without  a  direct  request"  (IEEE  Std 
1003.0-1995) 

Information  Technology:  Technology  related  to  computer  hardware  and  software  for  the 
processing,  storage,  and  transfer  of  information. 

Informational:  Informational  standards  include  those  remaining  standards  that  fall  outside  the 
official  DOD  statuses  of  "mandated,"  "adopted,"  "emerging,"  and  "legacy." 

Interface:  "A  shared  boundary  between  two  functional  entities.  A  standard  specifies  the  services 
in  terms  of  the  functional  characteristics  and  behavior  observed  at  the  interface.  The  standard  is  a 
contract  in  the  sense  that  it  documents  a  mutual  obligation  between  the  service  user  and  provider 
and  assures  stable  definition  of  that  obligation."  (IEEE  Std  1003.0-1995) 

Internationalization:  "The  process  of  designing  and  developing  an  implementation  with  a  set  of 
features,  functions,  and  options  intended  to  satisfy  a  variety  of  cultural  environments."  (IEEE  S  J 
1003.0-1995) 

Interoperability:  "The  ability  of  two  or  more  systems  to  exchange  information  and  to  use  the 
information  that  has  been  exchanged."  (IEEE  Std  1003.0-1995) 

Language-Binding  API  specification:  "A  specification  that  documents  the  source  code 
method,  consistent  with  a  specific  programming  language,  used  by  an  application  to  access 
services  provided  by  an  application  platform."  (IEEE  Std  1003.0-1995) 

Language-Independent  Service  Specification:  "A  specification  that  defines  a  set  of  required 
functional  semantics  independent  of  the  syntax  and  semantics  of  a  programming  language." 

(IEEE  Std  1003.0-1995) 
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Locale:  "The  definition  of  the  user  environment  that  depends  on  language  and  cultural 
conventions."  (IEEE  Std  1003.0-1995) 

Loss-less  Compression:  A  compression  technique  that  compresses  data  (or  an  image)  without 
losing  any  bits  or  deteriorating  the  resolution  of  an  image.  Compression  ratios  are  not 
tremendously  high  in  this  type  of  compression. 

Lossy  Compression:  A  compression  technique  that  compresses  data  (or  an  image)  but  loses  bits 
in  the  process.  The  quality  of  the  image  may  deteriorate;  however,  extremely  high  compression 
ratios  may  be  obtained  in  this  type  of  compression. 

Local  Adaptation:  "The  process  of  modifying  a  product  that  is  specific  to  one  culture  to  make  it 
specific  to  another  culture."  (IEEE  Std  1003.0-1995) 

Localization:  "The  process  of  utilizing  the  internationalization  features  to  adapt  an 
internationalized  product  to  a  specific  cultural  environment."  (IEEE  Std  1003.0-1995) 

Mqjor  Service  Area:  A  major  service  area  (MSA)  is  one  of  the  basic  categories  of  services 
required  by  information  systems.  The  MSAs  are  Software  Engineering,  User  Interface,  Data 
Management,  Data  Interchange,  Graphics,  Communications  and  Network,  and  Operating  System 
Services. 

Mandated  Standard:  The  DOD  status  "Mandated"  is  used  for  those  standards  mandated  by  the 
JTA.  A  standard  is  mandatory  in  the  sense  that  IF  a  service/interface  is  going  to  be  implemented, 
it  shall  be  implemented  in  accordance  with  the  associated  standard.  If  a  required  service  can  be 
obtained  by  implementing  more  than  one  standard,  the  appropriate  standard  should  be  selected 
based  on  system  requirements. 

Modularity:  The  property  of  a  system  that  has  been  decomposed  into  a  set  of  cohesive  and 
loosely  coupled  mcdules.  (See  Object-Based  and  Object-Oriented  Language) 

Object  (Instance,  Software  Object):  An  object  is  a  software  entity  that  has  state,  behavior,  and 
identity;  the  structure  and  behavior  of  similar  objects  are  defined  in  their  common  class;  the  terms 
instance  and  object  are  interchangeable. 

Object-Based  Language:  Any  programming  language  that  supports  some  but  not  all  of  the 
characteristics  of  Abstraction,  Encapsulation,  Modularity,  and  Hierarchy.  . 

Object-Oriented  Language;  Any  programming  language  that  fully  supports  the  characteristics 
of  Abstraction,  Encapsulation,  Modularity,  and  Hierarchy. 

Obsolescent:  An  indication  that  a  certain  feature  may  be  considered  for  withdrawal  in  future 
revisions  of  a  standard. 
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Open  Specifications:  'Specifications  that  are  maintained  by  an  organization  that  uses  an  open, 
public  consensus  piocess  to  accommodate  new  technologies  and  user  requirements  over  time." 
(IEEE  Std  1003.0-1995) 

Open  System:  "A  system  that  implements  sufficient  open  specifications  or  standards  for 
interfaces,  services,  and  supporting  formats  to  enable  properly  engineered  applications  software: 

a.  To  be  ported  with  minimal  changes  across  a  wide  range  of  systems  from  one  or 
more  suppliers 

b.  To  interoperate  with  other  applications  on  local  and  remote  systems 

c.  To  interact  with  people  in  a  style  that  facilitates  user  portability"  (IEEE  Std 
1003.0-1995) 

Open  System  Application  Program  Interface:  "A  combination  of  standards-based  interfaces 
specifying  a  complete  interface  between  an  application  program  and  the  underlying  application 
platform,"  (IEEE  Std  1003.0-1995) 

Open  System  Environment  (OSE):  "A  comprehensive  set  of  interfaces,  services,  and 
supporting  formats,  plus  user  aspects  for  interoperability  or  for  portability  of  applications,  data,  or 
people,  as  specified  by  information  technology  standards  and  profiles."  (IEEE  Std  1003.0-1995) 

Option:  "A  portion  of  the  specification  within  a  standard  that  is  not  required  to  be  present  in  a 
conforming  implementation."  (See  also  Conditional  Feature.)  (IEEE  Std  1003.3-1991) 

Performance:  "A  measure  of  a  computer  system  or  subsystem  to  perform  its  functions;  for 
example,  response  time,  throughput,  number  of  transactions  per  second.  The  efficiency  of  a 
system  in  accomplishing  pieces  of  work  is  an  attribute  of  performance."  (IEEE  Std  1003.0-1995) 

Performance  Requirement:  "A  requirement  that  specifies  a  performance  characteristic  that  a 
system  or  system  component  must  possess;  for  example,  speed,  accuracy,  frequency."  (IEEE  Std 
1003.0-1995) 

Platform  Internal  Interface  (PH):  "The  interface  between  application  platform  service 
components  within  that  platform."  (IEEE  Std  1003.0-1995) 

Platform  Profile:  "A  profile  whose  focus  is  on  functionality  and  interfaces  for  a  particular  type 
of  platform,  which  may  be  a  single  processor  shared  by  a  group  of  applications  or  a  large 
distributed  system  with  each  application  dedicated  to  a  single  processor."  (IEEE  Std  1003.0- 
1995) 

Portability  (application  software):  "The  ease  with  which  application  software  and  data  can  be 
transferred  from  one  application  platform  to  another."  (IEEE  Std  1003.0-1995) 

POSIX  (Portable  Operating  System  Interface  for  Computer  Environments):  The  term 
"POSIX”  has  been  evolving  into  a  term  with  a  number  of  different  meanings.  POSIX  is  sometimes 
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used  to  denote  the  formal  standard  ISO/DEC  9943-1:1990,  sometimes  to  denote  that  standard  plus 
related  standards  and  drafts  emerging  from  IEEE  PASC  working  groups,  and  sometimes  to 
denote  the  groups  themselves.  This  guide  refers  to  the  original  POSIX  standard  by  its  standard 
designation,  ISO/IEC  9945-1:1990,  and  not  by  the  term  POSIX. 

The  IEEE  groups  developing  standards  related  to  IEEE  P1003  are  called  IEEE  P1003.n  working 
groups.  Examples  are  the  IEEE  working  groups  P1003.2  and  P1003.3,  etc.  The  names  of  the 
groups  are  sometimes  abbreviated  POSIX.2,  POSIX.3,  etc.,  but  this  convention  is  not  used  by 
this  guide;  confusion  could  result  when  the  IEEE  P1003  decimal  number  does  not  match  the 
ISO/DEC  9945  part  number  (such  as  with  P1003.7  and  ISO/IEC  9945-3).  Furthermore,  other 
IEEE  open  systems  working  groups  such  as  P1224  do  not  use  the  POSIX  prefix.  Therefore,  all 
IEEE  projects  and  working  groups  are  referred  to  uniformly  as  Pnnnn. 

The  standards  emerging  out  of  the  POSIX  working  groups  are  referred  to  by  their  formal  names 
(e.g.,  IEEE  Std.  1003.2-1992  or  IEEE  P1003.10/D9)  and  are  called  either  POSIX  Base 
Standards  or  POSIX  Standardized  Profiles  (POSIX  SPs).  (IEEE  Std  1003.0-1995) 

POSIX  Standardized  Profile  (POSIX  SP):  "A  Standardized  Profile  that  specifies  the 
application  of  certain  POSIX  base  standards  in  support  of  a  class  of  applications  and  does  not 
require  any  departure  from  the  structure  defined  by  the  Reference  Model  for  POSIX  systems." 
(IEEE  Std  1003.0-1995) 

Process:  "An  address  space  and  one  or  more  threads  of  control  that  execute  within  that  address 
space,  and  their  required  system  resources."  (IEEE  Std  1003.0-1995) 

Product  Implementation:  The  usable,  binary  loadable  code  sold  by  vendors  and,  in  some  cases, 
bundled  with  hardware. 

Profile:  "A  set  of  one  or  more  base  standards,  and,  where  applicable,  the  identification  of  chosen 
classes,  subsets,  options,  and  parameters  of  those  base  standards,  necessary  for  accomplishing  a 
particular  function."  (IEEE  Std  1003.0-1995) 

Profile,  Standard's:  A  listing  of  the  specific  set  of  options  from  a  standard  that  will  be 
implemented  to  satisfy  a  system's  requirements. 

Profile  of  Standards:  A  list  of  the  standards  to  be  applied  in  a  given  system  or  functional  area. 

Programming  l  anguage  API  specification:  "The  interface  between  applications  and 
application  platforms  traditionally  associated  with  programming  language  specifications,  such  as 
program  control,  math  functions,  string  manipulation."  (IEEE  Std  1003.0-1995) 

Proprietary  Specification:  A  specification  developed  and  marketed  by  a  company  having 
exclusive  rights  to  modify  and  sell  it  The  specification  may  be  changed  at  will  by  the  owner 
without  going  through  a  standards  body  consensus  process. 
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Protocol:  "A  set  of  semantic  and  syntactic  rules  that  determine  the  behavior  of  entities  that 
interact"  (IEEE  Std  1003.0-1995) 

Public  Specifications:  "Specifications  that  are  available,  without  restriction,  to  anyone  for 
implementation,  sublicensing,  and  distribution  (i.e.,  sale)  of  that  implementation."  (IEEE  Std 
1003.0-1995) 

Reference  Model:  "A  structured  collection  of  concepts  and  their  relationships  that  scope  a 
subject  and  enable  the  partitioning  of  the  relationships  into  topics  relevant  to  the  overall  subject 
and  that  can  be  expressed  by  a  common  means  of  description."  (IEEE  Std  1003.0-1995) 

Scalability:  "The  ability  to  provide  functionality  up  and  down  a  graduated  series  of  application 
platforms  that  differ  in  speed  and  capacity."  (IEEE  Std  1003.0-1995) 

Security:  "The  protection  of  computer  resources  (e.g.,  hardware,  software,  and  data)  ffom 
accidental  or  malicious  access,  use,  modification,  destruction,  or  disclosure.  Tools  for  the 
maintenance  of  security  are  focused  on  availability,  authentication,  accountability,  confidentiality, 
and  integrity."  (IEEE  Std  1003.0-1995) 

Single-standard  Profile:  "A  single-standard  profile  (such  as  FIPS  Publication  151-2)  may 
consist  of  a  subset  of  a  particular  standard  or  a  single  standard  where  parameters  and  options  have 
been  selected.  This  type  of  profile  is  often  used  when  there  is  a  wide  range  of  options  and 
parameters  in  a  base  standard  and  specifying  these  options  can  focus  implementation  efforts.  It  is 
important  to  be  aware  that  some  base  standards  reference  other  base  standards  normatively  even 
when  defining  a  singe-standard  profile."  (IEEE  Std  1003.0-1995) 

Software:  "The  programs,  procedures,  rules,  and  any  associated  documentation  pertaining  to  the 
operation  of  an  information  processing  system."  (IEEE  Std  1003.0-1995) 

Spanning  Service  Area:  Spanning  service  area  volumes,  as  used  in  this  1TSG,  are  constructed 
for  any  subject  domain  that  crosses  major  service  areas. 

Specification:  "A  document  that  prescribes,  in  a  complete,  precise,  verifiable  manner,  the 
requirements,  design,  behavior,  or  characteristics  of  a  system  or  system  component."  (IEEE  Std 
1003.0-1995) 

Standard:  "A  document,  established  by  consensus  and  approved  by  an  accredited  standards 
development  organization,  that  provides,  for  common  and  repeated  use,  rules,  guidelines,  or 
characteristics  for  activities  or  their  results,  aimed  at  the  achievement  of  the  optimum  degree  of 
order  and  consistency  in  a  given  context."  (IEEE  Std  1003.0-1995) 

Standard  Feature:  "A  function  provided  in  a  standard.  Either  a  single  facility  or  behavior,  or, 
one  of  a  pair  of  alternative  facilities  or  behaviors,  required  by  a  standard  that  is  always  present  on 
aconforming  implementation."  (IEEE  Std  P 1 003.2- 1 99 1 ) 
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Standard  Profile:  A  profile  of  standards,  not  necessarily  having  gone  through  a  process  as  a 
standardized  profile. 

Standardized  Profile:  "A  balloted,  formal,  harmonized  document  that  specifies  a  profile." 

(IEEE  Std  1003.0-1995) 

Standard  Development  Organization:  "An  accredited  organization  that  formally  develops  and 
coordinates  standards  for  use  by  a  community.  (IEEE  Std  1003.0-1995) 

Standards  Implementation:  A  product  that  implements  a  standard. 

Standard's  Profile:  see  Profile,  Standard's. 

Supported:  A  condition  regarding  optional  functionality.  (ISO/IEC  9945-1) 

System  Documentation:  "All  documentation  provided  with  an  implementation,  except  the 
conformance  document."  (ISO/IEC  9945-1) 

Tailoring  Guidance:  Guidance  concerning  a  specific  information  processing  standard  on  the 
specific  features,  modes,  switch  settings,  functions,  areas  of  deficiencies,  extensions,  levels,  and 
options.  This  information  is  provided  to  tailor  the  specification  for  use  to  exploit  it  best  for 
eventual  transportability  at  the  source  code  level. 

Thread:  "A  single  flow  of  control  within  a  process."  (IEEE  Std  1003.0-1995) 

Transaction:  "A  unit  of  work  consisting  of  an  arbitrary  number  of  individual  operations,  all  of 
which  will  either  complete  successfully  or  abort  with  no  effect  on  the  intended  resources.  A 
transaction  has  well-defined  boundaries.  A  transaction  starts  with  a  request  from  the  application 
program  and  either  completes  successfully  (commits)  or  has  no  effect  (abort).  Both  the  commit 
and  abort  signify  completion  of  a  transaction."  (IEEE  Std  1003.0-1995) 

Transaction  Application  Program:  "Transactions  have  boundaries  (start  points  and  end  points) 
that  are  determined  by  the  action  of  the  transaction  application  program.  The  transaction 
application  program  can  request  either  to  commit  or  roll  back  the  work  done  in  the  transaction 
when  it  identifies  the  end  point.  The  system  will  complete  a  commit  operation  only  if  all 
operations  performed  during  the  transaction  can  complete  successfully.  Otherwise,  the  system 
will  abort  the  transaction  (roll  back  the  work  done  by  it)  and  notify  the  transaction  application 
program  of  this  action."  (IEEE  Std  1003.0-1995) 

Undefined:  "An  indication  that  a  part  of  the  standard  imposes  no  portability  requirements  on  an 
application's  use  of  an  indeterminate  value  on  its  behavior  with  erroneous  program  constructs  or 
erroneous  data. "  (ISO/IEC  9945- 1 ) 

Unspecified:  "An  indication  that  a  part  of  a  standard  imposes  no  portability  requirements  on 
applications  for  correct  program  constructs  or  correct  data  regarding  a  value  on  behavior." 
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(ISO/IEC  9945-1) 

Validation:  “The  process  of  testing  an  application  or  system  to  ensure  that  it  conforms  to  its 
specification."  (IEEE  Std  1003.0-1995) 
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2.7  Notes. 


2.7.1  Comments.  The  Center  for  Standards  solicits  comments  on  the  ITSG  and  experiences  in 
using  standards  from  users  of  this  document.  Use  of  a  standard  format  for  submitting  a  change 
proposal  will  expedite  the  processing  of  changes.  The  following  format  is  suggested  for  use  in 
responding  with  comments  or  other  useful  information  about  specific  instances  of  use  of 
standards. 

a.  Point  of  Contact  Identification 

(1)  Name: 

(2)  Organization  and  Office  Symbol: 

(3)  Street: 

(4)  City: 

(5)  State: 

(6)  Zip  Code: 

(7)  Area  Code  and  Telephone  #: 

(8)  Area  Code  and  Fax  #: 

(9)  E-mail  Address: 

b.  Document  Identification 

(1)  Volume  Number: 

(2)  Document  Title: 

(3)  Version  Number: 

(4)  Version  Date: 

c.  Proposed  Change  #  1 

(1)  Section  Number: 

(2)  Page  Number: 

(3)  Title  of  Proposed  Change: 

(4)  Wording  of  Proposed  Change: 

(5)  Rationale  for  Proposed  Change: 

(6)  Other  Comments: 

d.  Proposed  Change  #2 

(1)  Section  Number: 

(2)  Page  Number: 

(3)  Title  of  Proposed  Change: 

(4)  Wording  of  Proposed  Change: 

(5)  Rationale  for  Proposed  Change: 

(6)  Other  Comments: 

e.  Proposed  Change  #n 

(1)  Section  Numoer: 

(2)  Page  Number: 

(3)  Title  of  Proposed  Change: 

(4)  Wording  of  Proposed  Change: 

(5)  Rationale  for  Proposed  Change: 

(6)  Other  Comments: 
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The  preferred  method  of  proposal  receipt  is  via  e-mail  in  ASCII  format,  sent  via  the  Internet  If 
not  e-mailed,  the  proposal  change,  also  in  the  format  shown,  on  both  paper  arri  floppy  disk, 
should  be  mailed.  As  a  final  option,  change  proposals  may  be  sent  via  fax;  however,  delivery 
methods  that  enable  electronic  capture  of  change  proposals  are  preferred.  Address  information  for 
proposing  comments  is  shown  below. 

Internet:  bookera  @  ncr.disa.mil  or 

Mail:  DISA/JIEO/CFS  or 

Code:  JEBEA  (Angela  Booker) 

10701  Parkridge  Blvd 
Reston,  VA  20191-4357 

Fax:  703-735-3257  or 

Voice:  703-735-3536 

The  status  of  comments  on  the  ITSG  are  recorded  in  a  database,  and  the  comments  themselves 
are  distributed  to  working  groups  for  resolution. 


jpratt@logicon.com 

Logicon 

Attn:  John  Pratt 

1831  Wiehle  Avenue,  Suite  300 

Reston,  VA  20190-5241 

703-318-1098 


April  7,  1997 


2.7-2 


Version  3. 1 


INFORMATION  TECHNOLOGY  STANDARDS  GUIDANCE 


(ITSG) 

(Part  1  of  14  parts) 
INTRODUCTION/GUIDE 


Version  3.1  -  April  7, 1997 


AREA  IPSC 

DISTRIBUTION  STATEMENT  A:  Approved  for  public  release;  distribution  unlimited 


Information  Technology  Standards  Guidance 


Introduction/Guide 


3.1  Introduction/Guide.  The  detailed  requirements  sections  for  each  service  area  are  located  in 
separate  parts  of  the  ITSG.  Refer  to  Table  2.2-1,  section  2.2,  to  view  the  major  and  spanning 
service  areas  and  the  part  of  the  ITSG  document  in  which  these  service  areas  are  located. 
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32  Software  engineering  services.  Software  engineering  services  cover  all  Open  System 
Environment  (OSE)  services  related  to  the  support  of  information  systems  development  These 
services  include,  but  are  not  limited  to,  Computer  Aided  Software  Engineering  (CASE),  software 
life  cycle  processes,  programming  languages,  and  language  bindings. 

NOTE:  Throughout  Part  2,  all  tables  shall  have  abbreviations  listed  under  the  column  Standard 
Type  as  follows: 

a.  National  Public  Consensus  =  NPC. 

b.  International  Public  Consensus  =  IPC. 

c.  Government  Public  Consensus  =  GPC. 

d.  Consortia  Public  Consensus  =  CPC. 

e.  Corporate  Private  Non-Consensus  =  CPN-C. 

For  the  standard  reference  column  of  the  table  an  "R"  before  the  date  indicates  "reaffirmed." 

3.2.1  Software  engineering  environments.  Software  Engineering  Environments  (SEE)  provide 
a  set  of  services  across  one  or  more  life  cycle  phases  (e.g„  requirements,  implementation)  and 
support  development  activities  (e.g.,  design  and  coding).  A  SEE  consists  of  resources  (hardware, 
software,  tools)  and  an  integration  mechanism  (e.g.,  operating  system  or  framework),  and  is 
designed  around  a  set  of  supporting  standards  and  interfaces.  The  identified  SEE  standards  and 
interfaces  are  intended  to  facilitate  the  passing  of  information  and  data  internal  and  external  to  the 
SEE,  as  well  as  to  provide  access  to  required  services.  In  this  document,  emphasis  is  placed  on 
the  standards,  interfaces,  metadata  formats  and  guides  that  provide  the  basis  for  integration, 
expansion  and  tailoring  of  the  SEE,  its  tools  and  resources. 

3.2.1. 1  CASE/software  development  environment.  The  environments  and  tools  considered  are 
inclusive  of  all  integrated  CASE  environments.  The  identified  documents  support  extensive  and 
diverse  environments  containing  numerous  integrated  software  development  tools  that  span  the 
software  life  cycle.  These  environments  include  sets  of  tools,  firmware  devices  and  hardware 
necessary  to  support  the  development  and  design  of  software.  The  tools  span  a  broad  range  of 
services  and  may  include,  but  are  not  limited  to  analysis  tools,  design  and  test  tools,  simulation 
and  prototyping  tools,  code  generators  and  analyzers,  and  other  management  tools  used  in  SEEs. 

3.2.1. 1.1  Standards.  Table  3.2-1  presents  standards  for  software  development  environments. 


TABLE  3.2-1  CASE/software  development  environment  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status  1 
DoD  | 
(Lifecycle)  I 

NPC 

IEEE 

Recommended  Practice  for  the  Evaluation  and  Selection  of 
CASE  Tools 

1209:1993 

Adopted 

(Approved) 

'PC 

kcma 

Portable  Common  Tool  Environment  (PCTE)  -  Abstract 
Specification 

149(1994) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

IEEE 

Standard  Reference  Model  for  CompiMwig  Syatcm 
Enginecrim  Tool  Intcreoococtktti 

1175:1992 

Informational 

(Annoyed) 

NPC 

HA 

CDIF  interim  rtandatda  (CASE  Data  loterdunge  Format) 

1  J 

Iofosxnationa] 

(Approved) 

IPC 

ISO 

Portable  Common  Tool  Environment  (PCTE)  •  Pert  1: 
Abtfnct  Specification  (ECMA  149:1990) 

13719-1:1995 

Informational 

(Approved) 

NPC 

ANSI 

CASE  Tool  Integration  Metuget  (CTIM)  X3.273 

(X3H6) 

Informational 

(Drift) 

ECMA  149,  Portable  Common  Tools  Environment  (PCTE)  was  developed  by  the  European 
Economic  Community  (EEC),  ECMA,  and  European  regional  standards  organizations.  ECMA 
149  is  an  abstract  specification  of  a  tool  portability  interface.  The  document  has  matured,  with 
international  collaboration,  and  is  incorporated  in  ISO  1 37 1 9- 1 : 1 994. 

The  IEEE  standard  1 175  is  a  Standard  Reference  Model  for  Computing  System  Engineering  Tool 
Interconnections.  The  core  of  this  standard  is  the  Semantic  Transfer  Language  (STL),  which 
describes  concepts  such  as  data,  conditions,  events,  and  states,  as  well  as  transformation,  control- 
transition,  and  state-transition  operations.  This  standard  supports  both  textual  and  graphical 
forms. 

CASE  Data  Interchange  standards,  such  as  the  Electronics  Industries  Association's  (ELA)  CASE 
Data  Interchange  Format  (CDIF),  (eventually  to  become  three  ISO  standards)  for  the  exchange  of 
information  between  CASEs.  The  three  standards  address:  a  framework  standard,  a  syntax 
standard,  and  a  '  -antic  standard.  When  completed  these  standards  will  provide  data  interchange 
among  CASE  tools  used  in  an  integrated  CASE  environment. 

3.2.1. 1.2  Alternative  specifications.  No  alternative  specifications  are  known. 

3. 2. 1.1 -3  Standards  deficiencies.  Implementations  of  existing  standards  are  scarce.  PCTE  has 
only  two  known  environment  implementations  (TRANSTAR  and  PORTOS).  A  previous 
implementation  of  PCTE,  Emeraude,  is  now  called  TRANSTAR.  Many  tools  requiring 
encapsulation  into  the  PCTE  framework  already  exist  and  have  been  integrated  into  the  UNIX 
environment.  Customers  using  these  tools  and  wanting  to  migrate  into  the  PCTE  world  would 
have  to  encapsulate  something  that  already  has  been  integrated  into  a  potential  environment  on 
the  UNIX  side.  The  latter  would  be  an  inefficient  means  of  integrating  a  tool  into  the  PCTE  side 
of  the  house,  despite  the  need  for  the  existence  of  such  (especially  if  the  user  already  has  these 
tools  resident  within  his  UNIX  environment).  The  increased  popularity  of  the  CORBA 
specification  may  preclude  PCTE  usage  and  obviate  the  need  for  such. 

3.2.1. 1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 
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3.2.1. 1.5  Related  standards.  The  following  list  contains  additional  references: 

a.  Reference  Model  for  SEE  Frameworks  (NIST  SP-500-21 1/ECMA  TR/55). 

b.  Next  Generation  Computer  Resources  for  Project  Support  Environments  V2.0 
(RM  PSE)  NIST  SP-500-213. 

c.  Other  related  integrated  software  development  services,  such  as  A  Tool 
Integration  Standard  (ATIS),  have  been  proposed  in  the  U.S.,  (by  the  CASE 
Integration  Services  Committee  (CIS)  working  with  ANSI),  and  Europe. 

3.2.1.1.6  Recommendations.  ANSI/IEEE  1209  is  the  recommended  standard  for 
CASE/software  development,  but  additional  definitions  can  be  found  in  NIST  SP  500-213.  To 
ensure  uniformity  and  consistency  of  service  definitions  between  vendors,  contractors,  tools, 
integrators,  etc.,  NIST  SP  500-21 1,  Reference  Model  for  SEE  Frameworks,  is  a  technical  report 
containing  an  extensive  set  of  service  descriptions  and  definitions  for  a  SEE  framework  from 
which  tools  may  be  selected.  The  report  presents  consensus  definitions  of  services  and  is  intended 
to  assist  individuals  in  communicating  and  identifying  information  relative  to  SEE  services  for 
making  companions,  adjudicating  differences  in  implementations,  and  resolving  issues.  It  is 
recommended  when  defining  framework  and  software  engineering  services.  The  document  was 
developed  with  the  participation  from  ECMA  and  DOD,  with  a  corresponding  version  published 
by  ECMA  for  the  European  community. 
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3 2.1.2  Reusable  source  code  libraries.  Emerging  and  maturing  reusable  source  code  libraries 
are  collections  of  components  that  can  be  compiled  for  reuse  on  different  machines  with  different 
applications.  A  number  of  government  agencies  and  commercial  enterprises  are  currently  involved 
in  reusable  libraries.  Use  of  the  term  library  is  intended  to  imply  certification  of  the  reusable 
components.  Reusable  components  include  models,  design,  architectural  structures,  requirements, 
code,  documentation,  and  other  reusable  entity. 

3.2.1.2.1  Standards.  Table  3.2-2  presents  standards  for  reusable  source  code  libraries. 


TABLE  3.2-2  Reusable  source  code  libraries  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OMG 

Object  Management  Group  (OMG)  Object  CImi  Libraries 

Informational 

(Formative) 

3.2. 1.2.2  Alternative  efforts.  The  following  libraries  are  available: 

a.  DOD  Reuse  Libraries: 

•  Army  Reuse  Center  Library  and  Catalog  (ARC) 

•  C2MUG  Software  Catalog  (mathematics  and  various  Ada  functions) 

•  Common  Ada  Missile  Components  (CAMC) 

•  Software  Technology  for  Adaptable,  Reliable  Systems  Repository  (STARS) 

•  Defense  Software  Repository  System  (DSRS)  includes  nodes  at  DISA,  the 
Army  and  Air  Fc:.e. 

•  Comprehensible  Approach  to  Reusable  Defense  Software  (CARDS) 

•  Air  Force  Reuse  Center  Library  and  Catalog 

•  NASA's  Electronic  Services  and  Application  (ELSA) 

•  Asset  Source  for  Software  Engineering  Technology  (ASSET) 

•  CECOM  Weapon  System  Software  Catalog 

•  Reuse  Information  Clearinghouse 

•  Army  Topographic  Engineering  Center  (TEC) 

b.  Commercial  Reuse  Libraries: 

•  Booch's  Software  Components  for  Ada  95 

•  EVB  Generic  Reusable  Ada  Components  for  Engineering  (GRACE) 

•  NETL1B  Repository  at  University  of  Tennessee  (UTK) 

3.2. 1.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.1.2.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.2. 1.2.5  Related  standards.  Related  standards  are  unknown.  Reusable  source  code  standards 
have  yet  to  be  developed.  However,  companion  standards  to  software  reuse  are  DOD-STD-49X 
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and  EIA/IEEE  J-STD-016,  since  any  reuse  guidelines  must  be  consistent  with  them. 

Furthermore,  in  the  absence  of  formal,  adopted  standards,  the  following  reuse  guides  and 
docuim  'ts  may  be  of  assistance  in  addressing  the  reuse  issues: 

a.  DOD  Software  Reuse  Vision  and  Strategy,  July  1992,  DOD  Technical  Report 
1222-04-210/40,  NTIS  Accession  No.  ADA  260109. 

b.  Glossary  of  Software  Reuse  Terms,  NIST  Special  Publication  500-222,  December 
1992. 

c.  STARS  ASSET  Documents: 

•  CARDS  Technical  Concept,  STARS-AC-04107A/00 1/001 , 22  March  1993. 

•  Standards  and  Guidelines  for  Repository  Deliverables,  DT1C  AD-A240478, 

17  March  1989. 

•  Repository  Specifications,  DTIC  AD-A228467, 16  February  1990. 

•  Repository  Standards  and  Guidelines,  DTIC  AD-A228484, 17  March  1989. 

•  CARDS  Program  Document,  Engineer's  Handbook,  complements 
DOD-STD-498. 

3.2.1.2.6  Recommendations.  Standards  on  reuse  libraries  are  emerging  and  lag  behind  other 
standards.  Reuse  libraries  should  be  evaluated  to  identify  components  that  meet  functional 
requirements  and  are  cost  effective  over  the  life  of  the  system.  Effective  reuse  of  components  can 
be  achieved  if  early  system  life  cycle  requirements  and  domain  analysis  are  performed  to  identify 
potential  reuse  components  for  inclusion  into  a  repsoitory. 
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3.2.1  J  Specialized  language  and  compiler  tools.  Specialized  language  and  compiler  tools  are  a 
collection  of  traditional  operating  system-based  tools  to  update,  maintain,  and  regenerate 
programs,  develop  system  software,  and  provide  sophisticated  pattern  matching  functions. 

Operating  system-based  software  development  tools  are  a  collection  of  traditional  tools  to 
support  standardized  software  development,  maintenance,  management,  and  version  control. 

3.2.1.3.1  Standards.  Table  3.2-3  presents  standards  for  specialized  language  and  compiler  tools. 


TABLE  3.2-3  Specialized  language  and  compiler  tools  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

KM 

IPC 

ISO/IEC 

Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (at  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Opcn 

Single  Unix  Specification  (Spec.  1 170),  System  Interface 
Definition*,  Issue  4,  Version  2  (pert  of  XPG4) 

C434  (9/94) 

Emerging. 

(Approved) 

CPC 

X/Op cn 

Single  UNIX  Specification  (Spec.  1 170)  Commands  and 
Utilities,  Issue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  -  Part  2: 
Shell  and  Utilities  (adopts  ISO/IEC  9945-2:1993) 

FIPS  PUB 
189:1994 

Informational 

(Approved) 

NPC 

IEEE 

POSIX,  Part  2:  Shell  and  Utilities  -  (Additional  Utilities) 

P1003.2b 

Emerging 

(Draft) 

CPC 

X/Open 

Syrtem  V  Interface  Definition  (SVID)  (replaced  by  Single 

UNIX  Specification  (Spec.  1 170)) 

SVID  Issue4 

Informational 

(Superseded) 

3.2. 1.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  X/Open  (formerly  a  USL  specification):  SVR4. 

b.  Berkeley  4.3  Unix. 

c.  GNU  Tools,  debuggers,  other  utilities,  compilers,  and  specialized  languages 
(programs  from  the  Free  Software  Foundation). 

d.  BISON  YACC  PD  work  alike  from  GNU. 

e.  FLEX  LEX  PD  work  alike. 

f.  Mortice  Kern  Systems'  LEX  and  YACC  tools. 

g.  AFLEX  and  YACC  (ACADIA  PROJECT  tools  that  generate  Ada  code). 

h.  OSF:  OSF/l's  "lint"  (C  language  program  checker),  "m4"  (Expand  macro 
definitions),  "Id"  (Link  editor  for  object  files),  "as"  (Assembler). 
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3 2.133  Standards  deficiencies.  IEEE  1003.2/ISO/IEC  994S-2  lacks  most  of  the  programming 
language  and  compiler  facilities  present  in  XPG4,  SVID,  and  OSF/1,  such  as  the  link  editor  (“id"), 
macro  definition  expander  ("m4"),  the  assembler  ("as"),  the  C  language  program  checker  ("lint"), 
and  the  C  program  beautifier  ("cb").  These  utilities  are  important  enough  that  most  of  them  are 
supported  by  the  consortia. 

Operating  system-based  software  development  tool  standards  lack  most  traditional  UNIX-based 
software  development  utilities.  More  than  40  of  these  software  development  utilities  exist 
IEEE1003.2  and  1003.2a  combined  support  only  seven  utilities. 

POSIX  lacks  the  most  important,  most  widely  desired  of  the  software  development  utilities  -  the 
Source  Code  Control  System  (SCCS)  for  version  control. 

The  SVID  supports  a  large  number  of  software  development  utilities  not  existing  in  X/Open  or 
OSF/1. 

3.2.1.3.4  Portability  caveats.  The  IEEE  1003.2  standard  method  for  calling  the  compiler  to 
compile  standard  C  programs  is  "c89"  compared  to  the  "cc"  command  traditionally  used  to  call 
the  compiler. 

Incompatibility  errors  due  to  inconsistent  data  types  may  creep  into  programs  and  reduce  their 
portability  across  different  machines  and  with  different  applications  because  the  IEEE  1003.2 
standard  does  not  support  "lint,"  the  traditional  C  language  program  data-type  checker.  Although 
C  language  program  checkers  may  be  bundled  with  different  vendors'  systems,  user  portability  is 
reduced,  because  no  standard  interface  exists  for  invoking  or  using  these  program  checkers. 

The  POSIX  "awk"  utility  differs  from  traditional  awk  implementations  and  specifications  because 
of  POSIX  changes  made  to  support  internationalized  programs. 

The  options  specified  in  the  IEEE  1003.2  "awk"  are  different  from  any  specified  by  X/Open,  the 
SVID,  and  OSF/1.  X/Open  and  the  SVID  specify  the  same  options,  but  these  are  not  the  same  as 
those  specified  by  OSF/1. 

Most  of  the  UNIX-based  tools  related  to  software  development  are  licensed  by  AT&T,  while  the 
others  are  based  on  Berkeley  UNIX  and  licensed  from  U.C.  Berkeley.  These  tools  are  not 
necessarily  compatible.  The  incompatibility  almost  always  affects  the  interfaces  and  programmer 
portability,  but  does  not  necessarily  affect  source  code  portability. 

3.2.1.3.5  Related  standards.  The  NIST  Integrated  Software  Engineering  Environment  (1SEE) 
reference  model  discusses  operating  system-based  software  development  tools. 

3.2.1.3.6  Recommendations.  ISO/tEC  9945-2  as  profiled  by  FIPS  189  is  recommended  for 
language  and  compiler  tools. 
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3.2.2  Software  life  cycle  processes.  The  standards  listed  below  identify  the  software  life  cycle 
process.  This  is  the  process  that  begins  when  a  software  product  is  conceptualized  and  ends  when 
the  software  is  no  longer  available  for  use.  It  inclu  9e*  a  set  of  activities,  methods,  practices,  and 
transformations  that  are  used  to  develop  and  maintain  software  and  the  associated  products  (e.g., 
project  plans,  design  documents,  code,  test  cases,  and  user  manuals).  The  software  life  cycle 
typically  includes  a  concept  phase,  requirements  phase,  design  phase,  implementation  phase,  test 
phase,  installation  and  checkout  phase,  operation  and  maintenance  phase,  and  eventually  the 
retirement  phase. 

3 .2.2.1  Software  life  cycle.  This  section  presents  standards  for  the  overall  process  rather  than 
concentrating  on  single  aspects  of  the  cycle. 

3.2.2.1.1  Standards.  Table  3.2-4  presents  standards  for  software  life  cycle  processes. 


TABL^XM^Softw^reJifec^clestandards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

[PC 

ISO/1EC 

Software  Life  Cycle  Proceuei 

12207j  1995 

Adopted 

(Approved) 

OPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Developing  Software  Life  Cyde  Proceaiza 

1074:1992 

Informational 

(Approved) 

NPC 

E1A 

Trial  Uie  Standard  -  Standard  for  Information  Technology 
•  Software  Life-Cycle  Proceuei  •  Software  Development  - 
Acquirer-Supplier  Agreement 

Informational 

(Approved) 

GPC 

DOD 

Defenie  Syitem  Software  Development 

DOD-STD-2167A 

Informational 

(Superseded) 

OPC 

DOD 

DOD  Automated  Information  Syitem*  (AIS) 
Documentation  Standard! 

DOD-STD-7935A 

Informational 

(Superseded) 

NPC 

IBHR 

Standard  for  Information  Technology  •  Software  Life  Cycle 
Proceuei 

IEEE/EIA 

!2207US-daie 

Informational 

(Draft) 

NPC 

IRKR 

Guide  for  Information  Technology  *  Software  Life  Cycle 
Pioceuei  -  Life  Cycle  Data 

IEEE/EIA 

12207.  lUS-date 

Informational 

(Draft) 

NPC 

1BRR 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Proceuei  -  Implementation  Coniiderationi 

IEEE/EIA 

l2207.2US-date 

Infottnationai 

(Draft) 

3.2.2.1.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2. 1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.1.5  Related  standards.  The  NIST  ISEE  reference  model  discusses  operating  system-based 
software  development  tools. 
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3.2.2. 1.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOO  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/1EEE  J-STD-016: 1995  (formerly  IEEE  1498/EIA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  ELA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207. 1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207. 1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  ELA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/ELA  12207US  are  in  place. 
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3.2.2 2  Software  configuration  management.  (This  BSA  appears  both  in  part  2  and  part  9.) 
Configuration  management  is  the  process  of  applying  administrative  and  technical  procedures 
throughout  the  software  life  cycle  to  identity,  define,  and  baseline  configuration  items  for  software 
in  a  system;  control  modifications  and  releases  of  the  items;  record  and  report  the  status  of  the 
items  and  modification  requests;  ensure  the  completeness  and  correctness  of  the  items;  and 
control  storage,  handling,  and  delivery  of  the  items.  This  includes  activities  employed  by  the 
developer  to  identify  entities  (such  as  computer  files,  documents,  Computer  Software 
Configuration  Items)  whose  version  and  status  are  to  be  tracked  and  controlled,  to  apply  such 
controls,  to  keep  records  of  these  controls,  and  to  audit  that  these  controls  are  being  applied. 

3.2.2.2.1  Standards.  Table  3.2-5  presents  standards  for  software  configuration  management. 


TABLE  3.2-5  Software  configuration  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

I)o  I) 

(Lifecycle) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL- STD-498 

Adopted 

(Approved) 

NPC 

HA 

National  Consensu*  Standard  for  Configuration 
Management 

IS-649 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Configuration  Management 

1042:1987 

Informational 

(Approved) 

NPC 

ANSt/lBEE 

Software  Configuration  Management  Plan* 

828:1990 

Informational 

(Approved) 

QPC 

NIST 

Guideline  for  Software  Documentation  Management 

PIPS  PUB 
105:1984 

Informational  | 

(Approved)  | 

GPC 

POD 

Configuration  Management 

MIL«STD-973(I3): 

1995 

Informational  | 
(Approved) 

NPC 

HA 

Trial  U*e  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Proce**e*  -  Software  Development  - 
Acquirer-Supplier  Agreement 

Informational 

(Approved) 

NPC 

IBRR 

Standard  for  Inlormation  Technology  -  Software  Life  Cycle 
Proce**e* 

IEBE/EIA 

12207US-date 

Informational  j 

(Draft)  | 

NPC 

IHRR 

Guide  for  Information  Technology  •  Software  Life  Cycle 
Proceue*  -  Life  Cycle  Data 

IEEE/EIA 
12207, 11  JS-date 

Informational  1 

(Draft)  | 

I  NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Pjoces*es  -  Implementation  Comideratlon* 

IEEE/EIA 
12207.2  US- date 

Informational  1] 

(Draft)  | 

3.2.2.2.2  Alternative  specifications.  The  following  additional  guidance  document  is  also 
available;  Guidelines  for  Configuration  Management  (M1L-HDBK-761),  although  it  is  used  with 
MIL-STD-973(I3):  1995,  which  will  most  likely  be  canceled. 

3.2.2.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.2.5  Related  standards.  None. 
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32.22.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016: 1995  (formerly  IEEE  1498/EIA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-0 16  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipate!  that  IEEE/ELA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/ELA  12207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207. 1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207. 1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 
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32.2.3  Documentation  standards.  Documentation  standards  provide  the  process  for  recording 
information  produced  by  a  life-cycle  process  or  activity.  The  process  contains  the  set  of  activities 
that  plan,  design,  develop,  edit,  distribute,  and  maintain  those  documents  needed  by  managers, 
engineers,  and  users  of  the  system  or  software  for  configuration  management  and  system  life  cycle 
support. 

3.22.3.1  Standards.  Table  3.2-6  presents  standards  for  documentation. 


TABLE  3.2-6  Documentation  standards  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

GPC 

NIST 

Guideline  for  Software  Documentation  Management 

FIPS  PUB 
105:1984 

Infoimational 

(Approved) 

IPC 

ISO 

Documentation  Symbol  i  and  Convention*  for  Data, 
program  and  System  Flowcharts,  Program  Network  Charts, 
and  Syitem  Resources  Charts 

5807:1985 

Informational 

(Approved) 

tPC 

ISO 

Program  Flow  for  Prooeaiing  Sequential  File*  in  Terau  of 
Record  Groups 

6593:1985 

Informational 

(Approved) 

NPC 

fFFE 

Software  Teit  Documentation 

829:1983 

Informational 

(Approved) 

IPC 

ISO 

User  Documentation  and  Cover  Information  for  Consumer 
Software  Packages 

9127:1988 

Informational 

(Approved) 

IPC 

ISO 

Program  Constructs  and  Conventions  for  Their 
Representation 

8631:1989 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Recommended  Practice  for  Software  Design  Descriptions 

1016:1987 

Informational 

(Approved) 

NPC 

IEEE 

Taxonomy  for  Software  Engineering  Standard 

1002:1987 

Informational 

(Approved) 

IPC 

ISO 

Guidelines  for  the  Documentation  of  Compuler-basod 
Application  Systems 

6592:1985 

Informational 

(Approved) 

NPC 

ANSI/ANS 

Guidelines  for  the  Documentation  of  Digital  Computer 
Systems 

10.3:1986 

Informational  1 
(Approved) 

NPC 

IEEE 

Software  User  Documentation 

1063:1987 

Informational 

(Approved) 

NPC 

EIA 

Trial  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Processes  •  Software  Development  • 
Acquirer-Supplier  Agreement 

Informational 

(Approved) 

OPC 

DOD 

Defense  System  Software  Development 

DOD-STD-2I67A 

Informational 

(Superseded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (AIS) 
Documentation  Standsrds 

DOD-STD-7935A 

Informational 

(Superseded) 

I  NTC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cycle 
Processes 

IEEE/E1A 

!2207US-date 

Informational 

(Draft) 

I  ^ 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Life  Cycle  Data 

IEEE/EIA 
12207.  lUS-date 

Informational 

(Draft) 

1  NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Implementation  Considerations 

IEEE/EIA 

1 2207.2  US-date 

Informational 

(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Defeoae  Syrian  Software  Quality  Profram 

MIL-S  TD-2168 

Infnwndjnnal 

(Canceled) 

3.2.23.2  Alternative  specifications.  No  other  specifications  are  known. 

32.2.33  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.3.4  Portability  caveats.  Although  they  do  not  provide  software  portability,  these  standards 
can  be  used  to  facilitate  program  and  design  portability,  as  well  as  facilitating  the  development  of 
user  documentation. 

3.2.2.33  Related  standards.  None. 

32.2.3.6  Recommendations.  The  adopted  standard  is  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/1EEE  J-STD-016:  1995  (formerly  IEEE  1498/E1A  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/1EEE  trial  use  standard.  It  is 
anticipated  that  J-STD-0 16  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
standard  (12207.0US)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207. 1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/ELA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 
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3.2 .2.4  Joint  reviews.  Joint  reviews  are  processes  or  meetings  involving  representatives  of  both 
the  acquirer  and  the  developer,  during  which  t  ie  developer  presents  the  status  and  software 
products  of  a  life-cycle  activity  or  a  phase  of  a  project  to  the  acquirer  for  comment  and  approval. 
Joint  reviews  are  conducted  at  both  the  management  and  technical  levels  throughout  the  life  of  the 
contract. 


3.2.2.4.1  Standards.  Table  3.2-7  presents  standards  for  joint  reviews. 


Standard 

Type 

m 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Reviews  and  Audiu 

1028:1988 

Adopted 

(Approved) 

NPC 

TFCT-: 

Trial  USE  Standard  for  Applications  and  Management  of 
tbe  Systems  Engineering  Process 

1220:1994 

Informations] 

(Approved) 

NPC 

EIA 

Systems  Engineering 

632:1994 

Informational 

(Approved) 

NPC 

BA 

1  rial  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life- Cycle  Processes  -  Software  Development  - 
Acquirer- Supplier  Agreement 

— 

informational 

(Approved) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Jyde 
Processes 

IEEE/EIA 

12207US-date 

Informational 

(Draft) 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Life  Cycle  Data 

musi: 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Implementation  Considerations 

IEEE/EIA 

12207.2US-dale 

Informational 

(Draft) 

3.2.2A2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.4.3  Standards  deficiencies.  Deficiencies  in  the  existing  standaids  are  unknown. 

3.2.2.4.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.4.5  Rela*  ;d  standards.  None. 

3.2.2.4.6  Reco.  nendations.  The  adopted  standards  are  recommended. 

MILSTD-498  merges  and  supersedes  DDD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/EIA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  ioint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
stanaard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
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standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEEE  1028. 
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32.2S  Software  requirements.  Software  requirements  standards  cover  the  creation, 
manipulation,  and  representation  of  requirements.  They  may  include  software  capabilities,  data 
elements,  internal  and  external  software  interfaces,  system  software  and  hardware  configuration 
items  that  communicate  with  software  components,  and  system  states  and  modes  within  which  the 
specific  software  executes.  A  software  requirement  is  a  condition  or  capability  that  must  be  met 
by  software  that  a  user  needs  to  solve  a  problem  or  achieve  an  objective. 

3.2.2.5.1  Standards.  Table  3.2-8  presents  standards  for  software  requirements. 


TABLE  3.2-8  Software  requirements  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Software  Development  end  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Requirement!  Specification* 

830:1984 

Adopted 

(Approved) 

NPC 

HA 

Trial  U*e  Standard  -  Standard  lor  Information  Technology 
•  Software  Life-Cycle  Proceaae*  -  Software  Development  - 
Acquirer-Supplier  Agreement 

E1A/IEEB  J-STD- 
016:  1995 

Infomutional 

(Approved) 

GPC 

DOD 

Defense  Sy  atom  Software  Development 

DOD-STD-2I67A 

Informational 

(Superseded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (AIS) 
PooMnentatioo  Standard* 

DOD-STD-7935A 

Informational 

(Superseded) 

NPC 

WPP. 

Standard  for  Information  Technology  •  Software  Life  Cyde 
Proceaae* 

IEEE/E1A 

12207 US -dale 

Informational 

(Draft) 

NPC 

EEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Proceaae*  •  Life  Cycle  Data 

lEEfi/EIA 
12207.1  US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Proceaae*  -  Implementation  Considerations 

IEEE/EIA 

12207, 2US-date 

Informational 

(Draft) 

3.2.2 .5.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.5J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.5.5  Related  standards.  None. 

3.2.2.5.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  E1A/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/E1A  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  E1A/1EEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/E1A  I2207US,  the  U.S.  adaptation  of  ISO/IEC 
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12207,  will  be  sent  to  ANSI  f  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207 .2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  My  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  ELA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207 .2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEEE  830. 
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3.2.2.6  Software  design.  These  software  design  standards  provide  the  capability  to  capture, 
represent,  create,  analyze,  and  refine  the  design  attributes  of  the  software  components  of  a  system 
or  subsystem.  Their  attributes  can  be  the  structure  or  functionality  of  th*.  joftware  or  other 
characteristics  such  as  user  interface  design  or  performance  considerations.  Software  designs  are 
typically  dependent  on  a  set  of  requirements.  They  describe  interrelationships  of  software 
components,  including  interfaces,  invocation  parameters,  data  elements,  and  the  states  and  modes 
within  which  the  specific  software  sub-components  execute.  The  outcome  of  the  software  design 
includes  definition  of  the  software  components  and  subcomponents. 

3.2.2.6.1  Standards.  Table  3.2-9  presents  standards  for  software  design. 


TABLE  3.2-9  Software  design  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

OPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

i,.\  J 

Trial  Uie  Standard  •  Standard  for  Information  Technology 
-  '  .-2.  *  '  ife- Cycle  Prooeaaea  -  Software  Development  - 

Acquirer- Stagier  Agreement 

EIA/IEEE  J-STD- 
016:  1995 

Informational 

(Approved) 

NPC 

Lor  Software  Design  Deacription* 

1016.1:1993 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Rrco.  •  .■  T  ,4ice  for  Software  De*ign  Description* 

1016:1987 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Rt  •  ** »  Practices  for  Ada  ai  a  Program  Design 

Language 

990:1987 

Informational 

(Approved) 

GPC 

DOD 

Defense  System  Software  Development 

DOD-STD-2167A 

Informational 

(Superaeded) 

GPC 

DOD 

DOD  Automated  Information  System*  (A1S) 
Documentation  Standard* 

DOD-STD-7935A 

Informational 

(Superaeded) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cycle 
Processes 

1EEE/EIA 

12207  US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  *  Software  Life  Cycle 
Ptoceae*  -  Life  Cycle  Data 

IEEE/EIA 
12207.  lUS-dale 

Informational 
(Draft)  j 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  •  Implementation  Considerations 

IEEE/EIA 

12207.2US.date 

Informational  j 
(Draft) 

3.2. 2.6. 2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.6J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.6.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.6.5  Related  standards.  None. 

3.2.2.6.6  Recommendations.  The  adopted  standard  is  recommended. 
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MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/ELA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  1 2207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207. 1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 
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3.2.2.7  Software  management  indicators.  (This  BSA  appears  both  in  part  2  and  part  9.) 
Software  management  indicators  aid  in  managing  the  software  development  process.  Various 
measurements  of  both  software  products  and  software  processes  are  available.  Product 
measures(such  as  lines  of  code,  function  points,  etc.)  are  often  associated  with  the  product 
specification  and  should  be  used  as  management  indicators  throughout  the  product  life  cycle. 
Process  measures(such  as  software  trouble  reports)  should  be  tracked  to  determine  whether  the 
software  development  process  is  within  statistical  control  limits.  Key  indicators  should  be 
identified  in  the  software  development  plan,  and  the  developer  should  then  collect,  analyze, 
interpret,  take  corrective  actions,  and  report  on  the  selected  key  management  indicators. 

3.2.2.7.1  Standards.  Table  3.2-10  presents  standards  for  software  management  indicators. 


TABLE  3.2-10  Software  management  indicators  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL- STD-498 

Adopted 

(Approved) 

fPC 

ISO/IEC 

Quality  Characteririic*  and  Guidelines  for  Their  Uie 

9126:1991 

Adopted 

(Approved) 

NPC 

IEEE 

Use  of  Standard  Measure*  to  Produce  Reliable  Software 

982.2:1988 

Informational 

(Approved) 

NPC 

IEEE 

Standard  Dictionary  of  Measures  to  Produce  Reliable 
Software 

9821:1988 

Informational 

(Approved) 

NPC 

IKKK 

Software  Productivity  Metric* 

1045:1992 

Informational 

(Approved) 

NPC 

TERR 

Software  Quality  Metric*  Methodology 

1061:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Software  Life  Cycle  Proceue* 

12207:1995 

Informational 

(Approved) 

NPC 

EIA 

Trial  Uie  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Proceue*  •  Software  Development  - 
Acquirer-Supplier  Agreement 

E  LA/IEEE  J-STD- 
016:  1995 

Informational 

(Approved) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cycle 
Proceue* 

IEEE/EIA 

12207US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Proceue*  -  Life  Cycle  Data 

IEEE/EIA 

12207.  lUS-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  •  Software  Life  Cycle 
Processes  -  Implementation  Considerations 

IEEE/EIA 

12207.2US.date 

Informational 

(Draft) 

3.2  2.7.2  Alternative  specifications.  For  additional  metrics  information,  consult  the  following 
documents: 


a,  Metrics  for  1-CASE  Pilot  Project  (MIPP)  Program,  Metrics  Reporting  Guidebook, 
(prepared  by  Mitre  Corporation,  27  May  1994,  for  DISA/JlEO/CIMyTXEM). 
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b.  Practical  Software  Measurement:  A  Guide  to  Objective  Program  Insight,  Draft  12 
April  1995. 

c.  Streamlined  Integrated  Software  Metrics  Approach  (SISMA)  Guidebook; 
Application  of  STEP  Metrics,  (prepared  by  Software  Productivity  Solutions, 
Indialantic,  FL  32903, 12  July  1993,  for  the  U.S.  Army). 

d.  Software  Measurement  Guidebook,  (prepared  by  the  Software  Productivity 
Consortium  Services  Corporation,  December  1992,  Herndon  VA,  for  DARPA). 

32.2.73  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3J.2.7.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

32.2.7 £  Related  standards.  Related  software  management  guidance  can  be  found  in  the 
Software  Engineering  Institute's  Capability  Maturity  Model  (CMM).  The  Software  Engineering 
Institute's  CMM  provides  guidance  on  how  to  gain  control  of  the  software  development  and 
maintenance  processes.  The  CMM  has  defined  an  evaluation  procedure,  the  CMM  Based 
Appraisal  (CBA),  as  a  means  of  identifying  the  risks  associated  with  potential  contractor 
performance.  Diagnostic  tools  based  on  the  CMM  have  been  deployed.  One  of  those  tools,  the 
Software  Capability  Evaluation(SCE),  is  designed  to  be  used  by  an  acquiring  organization  to 
either  identify  process  risks  associated  with  a  particular  proposal  during  the  source  selection  or  to 
monitor  the  risk-reducing  process  improvements  during  the  contract  execution. 

3J.2.7.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  MIL-STD-498  contains  requirements  for  security  and  privacy  for  software 
development  and  documentation.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/EIA  IS  640) 
is  based  on  MEL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use 
standard.  It  is  anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as 
an  ANSI  standard  in  1997.  It  is  also  andcipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of 
ISO/IEC  12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a 
base  standard  (12207 .0US)  and  two  guides  (12207. 1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1  US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
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transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ISO/IEC  9126.  Appropriate  standards  should  be  selected 
based  on  software  metrics  requirements. 
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3 2.2.8  Software  testing  and  product  evaluation.  Software  testing  and  evaluation  standards 
support  the  test  and  evaluation  of  software  systems.  Testing  is  performed  on  individual  software 
components  (unit  testing),  on  collections  of  software  components  (integration  testing),  and  on 
complete  software  systems  (system  testing).  Evaluation  includes  in-process  software  evaluation, 
final  software  product  evaluation,  and  independent  evaluation  activities  to  ensure  the  functional 
completeness  of  the  configuration  items  against  their  requirements  and  the  physical  completeness 
of  the  configuration  items  (whether  its  design  and  code  reflect  an  up-to-date  technical 
description). 

3.2.2.8.1  Standards.  Table  3.2-1 1  presents  standards  for  software  testing  and  product  evaluation. 


TABLE  3.2-11  Software  testing  and  product  evaluation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hi 

GPC 

DOD 

Software  Development  and  Documentation 

MIL- STD-498 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Verification  and  Validation  Plans 

1012:1987 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Test  Documentation 

829:1983  (R1991) 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Unit  Testing 

1008:1987 

Adopted 

(Approved) 

NPC 

IEEE 

Guide  for  Software  Verification  and  Validation  Plana 

1059:1993 

Informational 

(Approved) 

GPC 

NIST 

Guide  for  Verification  and  Validation  Plana  (Adopta 
ANSI/IEEE  1012:1987) 

FIPS  PUB 
132:1987 

Informational 

(Approved) 

IPC 

ISO/IEC 

Software  Life  Cycle  Proceaaea 

12207:1995 

Informational 

(Approved) 

NPC 

EIA 

Trial  Uae  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Proceaaea  -  Software  Development  - 
Acquirer-Supplier  Agreement 

mm 

Informational 

(Approved) 

GPC 

DOD 

Defenae  System  Software  Development 

DOD-STD-2167A 

Informational 

(Superseded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (A1S) 
Documentation  Standards 

DOD-STD-7935A 

Informational 

(Superseded) 

NPC 

1FEP 

Stan' '  'd  for  Information  Technology  -  Software  Life  Cycle 
Processes 

IEEE/EIA 

12207  US -date 

Informational 

(Draft) 

NPC 

IKRB 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Life  Cycle  Data 

IEEE/EIA 
12207.1  US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Infonnalion  Technology  -  Software  Life  Cycle 
Processes  •  Implementation  Considerations 

IEEE/EIA 

!2207.2US-date 

Informational 

(Draft) 

3.2. 2.8. 2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.8J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
3.2.2.S.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
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3.2.2.8.5  Related  standards.  None. 

3 .2. 2.8.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL- STD-49 8  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  ELA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  ELA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IBEE/ELA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/ELA  12207US  will  consist  of  a  base 
standard  (12207 ,0US)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  ELA/IEEE  J-STD-0 1 6.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  conf<  miration  man  igement,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEEE  829,  ANSI/IEEE  1008,  and  ANSI/IEEE  1012. 


\ 
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32.2.9  Software  quality  assurance.  Software  quality  assurance  standards  provide  a  planned  and 
systematic  pattern  of  all  actions  necessary  to  provide  adequate  confidence  that  a  software  work 
product  conforms  to  established  technical  requirements.  Further,  it  provides  a  set  of  activities 
designed  to  evaluate  the  process  by  which  software  work  products  are  developed  and  maintained. 

3.2.2.9.1  Standards.  Table  3.2-12  presents  standards  for  software  quality  assurance. 


TABLE  3.2-12  Software  quality  assurance  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STEM98 

Adopted 

(Approved) 

IPC 

ISO 

Model  for  Quality  Assurance  in  Design,  Development, 
Production,  Inatalladoo  and  Servicing 

9001:1994 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Quality  Aisurance  Plans 

730.1:1989 

Adopted 

(Approved) 

IPC 

ISO 

IBH 

Adopted 

(Approved) 

NPC 

trer 

Software  Quality  Management  Systems,  Part  1 : 
Requirements 

1298:1992 

Adopted 

(Approved) 

NPC 

HA 

Trial  Uae  Standard  *  Standard  for  Information  Technology 
•  Software  Life-Cycle  Procures  -  Software  Development  - 
Acquirer-Supplier  Agreement 

BIA/1EEE  J-STD- 
016:  1995 

Informational 

(Approved) 

GPC 

DOD 

Defense  System  Software  Development 

DOD-STD-2167A 

Informational 

(Superseded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (AIS) 
Documentation  Standards 

DOD-STD-7935A 

Informational 

(Superseded) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cycle 
Prooetser 

IEEE/EIA 

12207  US -dale 

Informational 

(Drift) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  •  Life  Cycle  Data 

IEEE/EIA 
12207.  lUS-dale 

Informational 

(Drift) 

NPC 

TREE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Implementation  Considerations 

IEEE/EIA 

12207, 2US-date 

Informational 

(Draft) 

GPC 

DOD 

Defense  System  Software  Quality  Program 

MIL-STD-2168 

Informational 

(Canceled) 

3.2.2.9.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.9.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.9.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.9.5  Related  standards.  None. 

3.2.2.9.6  Recommendations.  The  adopted  standards  are  recommended. 
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MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/ELA  12207US,  the  U.S.  adaptation  of  ISO/IEC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/ELA  12207US  will  consist  of  a  base 
standard  (12207.0US)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207 ,2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  TTie  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEEE  730,  ISO  900 1 ,  ISO  9000-3  and  IEEE  1 298. 
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322.10  Software  problem  categories/priorities.  These  standards  provide  the  developer  with  a 
structured  format  to  prepare  a  corrective  action  and  process  improvement  system  for  software 
development  They  also  provide  a  procedure  for  handling  all  problems  detected  and  changes 
recommended  in  development  products  after  they  have  been  released  for  software  product 
evaluation.  This  includes  the  classification  by  category  and  priority  of  such  problems. 

3.2.2.10.1  Standards.  Table  3.2-13  presents  standards  for  software  problem  categories  and 
priorities. 


TABLE  3.2-13  Software  problem  categories/priorities  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

rPFP 

Qassificatioo  for  Software  Anomalies 

1044:1993 

Adopted 

(Approved) 

NPC 

BA 

Trial  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Processes  -  Software  Development  - 

Acquirer- Supplier  Agreement 

Informational 

(Approved) 

GPC 

DOD 

Defense  System  Software  Development 

DOD-STD-2167A 

Informational 

(Superseded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (AIS) 
Documentation  Standards 

DOD-STD-7935A 

Informational 

(Superseded) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cycle 

Processes 

IEBE/E1A 

12207  US- date 

Informational 

(Draft) 

NPC 

rrara 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Life  Cycle  Data 

IHEF/EIA 
12207.1  US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cycle 
Processes  -  Implementation  Considerations 

IEEH/EIA 

12207.2US-date 

Informational 
(Draft)  i 

3.2.2.10.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2.10.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.10.4  Portability  caveats.  Portability  problems  with  the  existing  standards  sire  unknown. 

3.2.2.10.5  Related  standards.  None. 

3.2.2.10.6  Recommendations.  The  adopted  standards  are  recommenced. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEF;  J-STD-016:  1995  (formerly  IEEE  1498/EIA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/E1A  12207US,  the  U.S.  adaptation  of  ISO/IEC 
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12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  ELA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transit'  >n  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEf  E  1044. 
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3>2.2.11  Software  safety.  (This  BSA  appears  in  both  Part  2:  Software  Engineering  and  Part  9: 
System  Management)  These  standards  provide  procedures  for  identifying  as  safety-critical  t»*~se 
CSCIs  or  portions  thereof  whose  failure  could  lead  to  a  hazardous  system  state  (one  that  ci  'ilu 
result  in  death,  injury,  loss  of  property,  or  environmental  harm).  The  developer  shall  develop  a 
safety  assurance  strategy,  including  both  tests  and  analyses,  to  assure  that  the  requirements, 
design,  implementation,  and  operating  procedures  for  the  identified  software  minimize  or 
eliminate  the  potential  for  hazardous  conditions.  The  objective  is  to  eliminate  hazards,  and  reduce 
the  associated  risk  to  a  level  of  acceptability  to  the  managing  activity. 

3.2.2.11.1  Standards.  Table  3.2-14  presents  standards  for  software  safety. 


TABLE  3.2-14  Software  safety  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

System  Safety  Program  Requirement! 

KHL-STD-882C: 

1996 

Adopted 

(Approved) 

NPC 

Software  Safety  Plant 

1228:1994 

Informational 

(Approved) 

3.2.2.11.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.2. 1 1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.2.11.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.11.5  Related  standards.  None. 

3.2.2.11.6  Recommendations.  MIL-STD-882C  is  recommended. 
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3.2.2.12  Software  support  The  standards  listed  below  identify  those  activities  that  take  place  to 
ensure  that  software  installed  at  user  sites  continues  to  perform  as  intended  and  fulfill  its  intended 
role  in  system  operation.  Software  support  includes  software  maintenance,  aid  to  users,  and 
related  activities. 

3.2.2.12.1  Standards.  Table  3.2-15  presents  standards  for  software  support 


TABLE  3.2-15  Software  support  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

NPC 

TPFF 

Software  Maintenance 

1219:1993 

Adopted 

(Approved) 

GPC 

NIST 

Guideline  on  Software  Maintenance 

FIPS  PUB 
106:1984 

Informational 

(Approved) 

GPC 

DOD 

Minion  Critical  Computer  Reaources  Software  Support 

MIL-HDBK- 

347:1990 

Informational 

(Approved) 

NPC 

H  A 

Trial  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Proceiaea  -  Software  Development  - 
Acquirer-Supplier  Agreement 

EIA/IEEE  J-STD- 
016:  1995 

Informational 

(Approved) 

NPC 

fPPR 

Standard  for  Information  Technology  •  Software  Life  Cyde 
Proceiaea 

IEEE/EIA 

12 207 US- date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cyde 
Piuceaaea  -  Life  Cycle  DaU 

IEEE/EIA 

12207.  lUS-date 

Informational 

(Draft) 

NPC 

IHBF. 

Guide  for  Information  Technology  -  Software  Life  Cyde 
Proceaaea  •  Implementation  Conn  deration! 

IEEE/EIA 

12207.2US-date 

Informational 

(Draft) 

3.2.2.12.2  Alternative  specifications.  No  alternate  specifications  are  known. 

3.2.2.12.3  Standards  deficiencies.  Deficient. .  in  the  existing  standards  are  unknown. 

3.2.2.12.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.2.12.5  Related  standards.  MIL-HDBK-347,  Mission-  Cr  al  Computer  Resources  Software 
Support,  provides  related  information. 

3.2.2.12.6  Recommendations.  The  adopted  standards  are  rec  amended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016:  1995  (formerly  IE  3  1498/EIA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  ft.’l  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/E1A  12207US,  the  U.S.  adaptation  of  1SO/1EC 
1 2207,  will  be  sent  to  ANSI  as  a  joint  standard.  1EEE/EIA  1 2'I97US  will  consist  of  a  base 
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standard  (12207.0US)  and  two  guides  (12207. 1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  ELA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ANSI/IEEE  1219. 
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3 -2.2.13  Software  distribution.  (This  BSA  appears  both  in  part  2  and  part  9.)  Software 
distribution  and  installation  services  comprise  utilities  for  packaging,  installing,  and  distributing 
software  for  use  on  heterogeneous  and  potentially  incompatible  systems.  These  services  will 
enable  network  managers  to  transmit  software  to  any  stand-alone  or  networked  system,  regardless 
of  the  media  used  for  distribution.  Standards  for  software  distribution  in  a  system  provide  a 
standardized  layout  for  distributing  and  installing  software  in  a  single  system  or  network.  They 
explicitly  define  each  phase  of  software  distribution,  installation,  and  configuration-covering  such 
distribution  media  as  disks,  tapes,  and  CD-ROM. 

3.2.2.13.1  Standards.  Table  3.2-16  presents  standards  for  software  distribution. 


TABLE  3.2-16  Software  distribution  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

POSIX  System  Atfcnmiitration  -  Pvt  2:  Software 
Administration  (former  P1003.7.2) 

1387.2:1995 

Adopted 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification  (Spec.  1 170) 

T908:  1995 

Emerging 

(Approved) 

CPC 

X/Opexi 

Syitemi  Management:  Distributed  Software  AdminiiUation 
(XDSA) 

P429:1997 

Informational 

(Approved) 

3.2.2.13.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Hewlett-Packard:  "swinstall"  and  "swpackage"  systems. 

b.  USG:  SVR4-based  "pkgadd"  system. 

c.  Santa  Cruz  Operation  (SCO):  "custom+"  system. 

3.2.2.13.3  Standards  deficiencies.  IEEE  1387.2  does  not  provide  for  acting  upon  log  files  in 
■emote  file  systems.  No  Ada  bindings  are  available  for  software  distribution  standards. 

3.2.2.13.4  Portability  caveats.  Although  the  IEEE  1387.2  standard  is  based  on  Hewlett- 
Packard’s  "swinstall"  and  "swpackage"  systems,  the  standard  has  modified  the  specifications  so 
that  they  are  not  exactly  like  the  HP  systems. 

3.2.2.13.5  Related  standards.  The  following  standards  are  related  to  software  distribution  or 
software  distribution  standards: 

a.  1SO/IEC  JTC1  IS  9595: 1991 :  Common  Management  Information  Service 
(CMIS). 

b.  ISO/IEC  JTC1  IS  9596:1991:  Common  Management  Information  Protocol 
(CM1P). 
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c.  ISO/IEC  IS  1 1578:  1996,  Information  Technology  -  Open  Systems 
Interconnection  -  Remote  Procedure  Call  (RPC). 

d.  Internet  RF'C  1 155  (STD  17):  Structure  and  Identification  of  Management 
Information  for  TCP/IP-based  Internets. 

e.  Internet  RFC  1 157  (STD  15):  A  Simple  Network  Management  Protocol. 

f.  Internet  RFC  1213  (STD  17):  Management  Information  Base  for  Network 
Management  of  TCP/IP-based  Internets  (MIB-II). 

g.  Network  Management  Forum:  OMNIPoint  1. 

3.2.2.13.6  Recommendations.  IEEE  1387.2  is  recommended. 

A  new  version  of  the  X/Open  Single  UNIX  Specification  (Spec.  1 170)  is  expected  to  be  issued  in 
1997. 
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3.2.2.14  Software  license  management  (This  BSA  appears  in  both  part  2  and  part  9.)  License 
management  addresses  the  problem  of  tracking  software  licenses  in  a  distributed  systems 
environment  The  DME  licensing  technology  includes  models  that  assist  users  in  keeping  track  of 
how  many  software  copies  are  needed  and  who  is  using  it  once  it  is  purchased.  Software  license 
management  for  a  system  provides  license  administration,  monitoring,  and  enforcement  services 
that  allow  more  detailed,  firm  and  equitable  licensing  terms  for  users,  and  better  protection 
against  illegal  software  usage  for  vendors. 

3.2.2.14.1  Standards.  Table  3.2-17  presents  standards  for  software  license  management 


TABLE  3.2-17  Software  license  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

POSIX  Syttem  Admmiitretion  -  Put  2:  Software 
Adminiitmion  (former  P  1X3.7 .2) 

1387.2:1995 

Adopted 

(Approved) 

CPC 

X/Open 

Syitom  Management:  Diitributed  Software  Adminiitradon 
(XDSA) 

P429:1997 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Management  Environment  (DME):  Licenie 
Management  (LM)  Service 

DMELM 

Informational 
(Hiitoric  (Not 
recommended)) 

3.2.2.14.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Hewlett-Packard:  Network  License  System  (NetLS)  Version  2.0  on  which  OSFs 
DME  License  Management  System  (LS)  is  based. 

b.  Gradient  Technologies:  PC  Client  libraries  for  license  management  and  PC  Ally 
server,  on  which  DME's  License  Management  PC  component  is  based. 

3.2.2. 14  J  Standards  deficiencies.  No  Ada  bindings  exist  for  any  of  the  configuration 
management  standards  or  consortia  specifications. 

3.2.2.14.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.2.2.14.5  Related  standards.  The  following  standards  are  related  to  license  management  or 
license  management  standards: 

a.  ISO/DECJTC1  IS  9595:1991:  Common  Management  Information  Service 
(CMIS). 

b.  ISO/IEC  JTCt  IS  9596:1991:  Common  Management  Information  Protocol 
(CMIP). 
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c.  ISO/IEC  IS  1 1578:  1996,  Information  Technology  -  Open  Systems 
Interconnection  -  Remote  Procedure  Call  (RPC). 

d.  Internet  RFC  1 1 55  (STD  17):  Structure  and  Identification  of  Management 
Information  for  TCP/IP-based  Internets. 

e.  Internet  RFC  1 157  (STD  15):  A  Simple  Network  Management  Protocol. 

f.  Internet  RFC  1213  (STD  17):  Management  Information  Base  for  Network 
Management  of  TCP/IP-based  Internets  (MIB-II). 

g.  Network  Management  Forum:  OMNIPoint  1. 

3.2.2.14.6  Recommendations.  IEEE  1387.2  is  recommended. 
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3 33  Programming  languages.  Programming  languages  include  all  languages  represented  by 
the  ISO,  the  European  Computer  Manufacturers'  Association  (ECMA),  the  International 
Electrotechnical  Commission  (IEC),  the  American  National  Standards  Institute  (ANSI),  the 
IEEE,  NIST,  or  DOD  standards,  as  well  as  those  used  by  DOD  but  not  represented  by  standards. 
Quotes  regarding  the  number  of  languages  used  by  DOD  range  from  50  to  300;  however,  this 
volume  only  includes  languages  playing  major  roles  in  DOD  systems  and  those  supporting  DOD- 
Wide  goals  of  economy,  interoperability,  and  portability. 

Certification  of  conformance  to  the  source  language  specification  results  in  a  higher  degree  of 
portability  across  platforms  for  all  languages.  Test  suites  to  validate  source  language  standards 
conformance  are  available  from  the  NIST,  the  IEEE,  and  the  Ada  Joint  Program  Office  (AJPO). 
Specific  conformance  test  suites  will  be  addressed  for  each  language  covered  in  this  document 

3.23.1  Programming  language  framework.  Coverage  of  language  standards  is  currently 
limited  to  those  Higher  Order  Languages  (HOL)  deemed  to  represent  the  majority  of  Commercial 
Off  The  Shelf  (COTS)  and  custom  applications  used  within  the  DOD.  The  relevant  standards  will 
be  listed  along  with  coverage  of  Standards  Deficiencies,  Portability  Caveats,  Tailoring  Guidance, 
Alternative  Specifications,  Related  Standards,  and  Recommendations  for  use. 

Public  Law  (PL)  102-172  states,  "Notwithstanding  any  other  provisions  of  law,  after  1  June  1991, 
where  cost  effective,  all  Department  of  Defense  software  shall  be  written  in  the  programming 
language  Ada,  in  the  absence  of  special  exemption  by  an  official  designated  by  the  Secretary  of 
Defense."  The  Assistant  Secretary  of  Defense  for  Command,  Control,  Communications,  and 
Intelligence  (ASD/C3I)  has  been  designated  as  the  DOD  Ada  Waiver  review  authority,  with  some 
responsibilities  delegated  to  the  services  and  the  Defense  Intelligence  Agency.  (ASD(C3I) 
Memorandum,  17  April  1992,  "Delegations  of  Authority  and  Clarifying  Guidance  on  Waivers 
from  the  Use  of  the  Ada  Programming  Language")  Software  used  by  the  DOD  includes 
Commercial  Off-the-Shelf  (COTS),  Government  Off-the-Shelf  (GOTS),  and  new  DOD-developed 
software.  New  DOD-developed  software  includes  custom  applications  as  well  as  software  to 
integrate  COTS  and  GOTS.  Ada  is  the  preferred  software  development  language  for  all  new  and 
revised  DOD-developed  software. 

3.23.1. 1  Standards.  Table  3.2-18  presents  standards  for  programming  languages. 


TABLE  3,2-18  Programming  language  framework  standards 


1  Standard 
Type 

Sponsor 

Standard 

Standard 

Reference 

Hiiim 

GPC 

NIST 

Ad*  (Adopt*  ANSI/ISO/IEC  8652:  1995) 

FIPS  PUB  119-1: 
1995 

Adopted 

(Approved) 

NPC/IPC 

ANSI/ISO/IEC 

Ada-95 

8652:1995 

Adopted 

(Approved) 

GPC 

NIST 

Pascal  (Adopts  ANSI/IEEE  770  X3.97-1983/RI990) 

FIPS  PUB 
109:1985 

Informational 

(Approved) 

April  7,  1997 


3.2-36 


Version  3.1 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

MUMPS  (Adopt*  ANSI/MDC  XI  1.1-1990) 

FIPS  PUB  125- 
1:1993 

Informational 

(Approved) 

GPC 

NIST 

BASIC  (ANSI  X3.I13-1987/R1993,  reflect*  major 
change*,  improvements  and  additions  to  the  BASIC 
specification*.) 

FIPS  PUB  68- 
2:1987/R1993 

Informational 

(Approved) 

GPC 

DOD  (USA F) 

JOVIAL  (J73) 

MIL-STD-I589C: 

1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Ada 

86S2:1987 

Inform  ad  otvJ 
(Approved) 

npc/ipc 

ANSI/ISO 

Programming  Language*:  C 

9899:1992 

Informational 

(Approved) 

GPC 

NIST 

C  (Adopt*  ANSI/ISO/IEC  9899:1992) 

FIPS  PUB 
160:1992 

Informational 

(Approved) 

IPC 

ISO 

FORTRAN-90 

1539:1991 

Informational 

(Approved) 

NPC 

ANSI 

FORTRAN-77 

X3.9-1978  (R1989) 

Informational 

(Approved) 

NPC 

ANSI 

COBOL 

X3.  23:  1993 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Pascal 

770X3.97-1983 

(R1990) 

Informational 

(Approved) 

IPC 

ISO 

Pascal 

7185:1983 

Informational 

(Approved) 

NPC 

ANSI 

COBOL 

X3. 23a:  1989 

Informational 

(Approved) 

GPC 

NIST 

COBOL  (adopt*  ANSI  X3.23a:  1989  and  X3.23b:  1993) 

FIPS  PUB  21- 

4:1995 

Informational 

(Approved) 

GPC 

DOD  (AJPO) 

Ada  Programming  Language 

MIL- STD- 
1815A:  1983 

Informational 

(Approved) 

IPC 

ISO/IEC 

C++ 

SC22  WG22, 
X3J16 

Informational 

(Draft) 

NPC 

ANSI/X3J13 

Common  LISP  (X3.226  Programming  Language  Common 
LISP) 

X3J 13/92- 101 

Informational 

(Draft) 

GPC 

NIST 

Ada 

FIPS  PUB 
119:1985 

Informational 

(Superseded) 

3.2.3.1.2  Alternative  specifications.  Although  many  language  standards  exist  other  than  HOLs 
listed  above,  the  coverage  of  languages  in  this  document  is  limited  to  those  HOLs  that  represent 
the  most  significant  percentage  of  DOD  applications. 


3.2.3. 1.3  Standards  deficiencies.  Each  programming  language  has  its  own  strengths  and 
weaknesses.  Details  containing  specific  language  strengths  and  weaknesses  are  contained  in 
language  rationale,  comparison  documents,  and  dissertations  external  to  the  standards  and  this 
document. 
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3. 2. 3. 1.4  Portability  caveats.  Despite  the  existence  of  programming  language  standards,  each 
vendor  and  platform  implementation  may  contain  features  not  included  in  the  standard. 
Furthermore,  conformance  to  the  standard  generally  is  neither  verified  nor  regulated  by  the 
standards  community.  Therefore,  portability  of  applications  written  in  a  specific  language  depends 
upon  these  factors: 

a.  The  extent  of  conformance  of  a  particular  implementation  to  the  standard. 

b.  The  range  of  operating  systems  for  implementations  of  the  language. 

c.  The  range  of  hardware  suites  for  implementations  of  the  language. 

In  all  cases,  the  extent  to  which  application  programmers  employ  nonstandard  features  is  a  major 
factor  in  determining  portability  across  platforms.  Portability  across  languages  also  is  affected  by 
the  factors  mentioned,  because  translation  from  one  source  language  to  another  requires  more 
human-intensive  effort  if  nonstandard  features  are  employed.  In  addition,  different  source 
languages  often  provide  different  mechanisms  for  abstracting  data  and  operating  on  data,  and 
employ  different  approaches  toward  interaction  with  the  operating  system  and  hardware.  For  this 
reason,  when  transitioning  from  any  source  language  to  another,  reverse  engineering  from  the 
current  specifications  is  preferred  over  simple  source  code  translation. 

3.2.3.1.5  Related  standards.  A  number  of  standards  exist  or  are  in  the  definition  process  for  Ada 
bindings  to  other  components  of  open  systems.  Section  3.2.4. 1  includes  a  table  which  lists  these 
standards. 

3.2.3. 1.6  Recommendations.  The  adopted  standards  are  recommended.  The  following  order  of 
,-eference  applies  to  developing  or  modifying  DOD  software  applications: 

a.  Reuse  existing  government-owned  code  without  modification  where  significant 
savings  in  maintenance  and  development  can  be  identified. 

b.  Use  COTS  software  that  is  conformant  with  DOD-adopted  standards  without 
modifications,  where  significant  savings  in  maintenance  costs  can  be  documented, 
although  DOD  will  not  maintain  COTS  software. 

c.  Modify  existing  Ada  code. 

d.  Develop  new  code  using  Ada.  Develop  or  modify  non- Ada  legacy  code. 

If  a  COTS  software  product  is  being  procured,  rather  than  a  software  product  being  developed, 
the  programming  language  used  by  the  developer  of  the  COTS  product  is  not  of  vital  concern, 
unless  it  is  expected  the  COTS  product  will  be  included  as  part  of  another  application.  If  the 
COTS  software  will  be  incorporated  into  a  larger  application,  one  must  carefully  consider  the 
extent  of  dependency  upon  the  COTS-provided  functions  and  have  an  understanding  of  the 
options  in  the  event  the  vendor  terminates  support  for  the  application. 
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3.23.2  Ada.  Ada  is  a  general  purpose  and  systems  programming  language  designed  with  an 
emphasis  on  reliability,  readability,  and  maintainability.  Originally  intended  for  embedded,  real¬ 
time  systems  development,  use  of  Ada  has  extended  into  the  MIS  community  and  is  appropriate 
for  a  broad  range  of  applications  areas.  Ada  is  a  language  that  enforces  modem  software 
engineering  principles  of  data  abstraction,  information  hiding,  and  modularity.  Ada  supports 
reusability  though  several  features  of  the  language:  explicit  support  for  program  units;  separation 
of  interface  specifications  from  the  hidden  body;  strong,  user  definable  typing  of  data  and 
operators;  overloading  of  function  and  procedure  names;  and  generic  units  to  supply 
parameterized  code  templates.  The  Ada  standard  (Ada-95)  brings  the  language  into  line  with 
newer  software  engineering  concepts  including  extensions  to  improve  support  for  real-time 
systems,  object-oriented  features,  and  mega-programming. 

3.23.2.1  Standards.  Table  3.2-19  presents  standards  for  Ada. 


TABLE  3.2-19  Ada  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

A<U  ( Adopt  i  ANSI/ISO/IEC  8652:  1995) 

FIPS  PUB  1 19-1: 
1995 

Adopted 

(Approved) 

NPC/IPC 

ANSI/ISO/IEC 

A(Ur95 

8652:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Ada 

8652:1987 

Informational 

(Approved) 

GPC 

DOD  (AJPO) 

Ada  Programming  Language 

MIL-STD- 
1 81 5  A:  1983 

Informational 

(Approved) 

GPC 

NIST 

Ada 

FIPS  PUB 
119:1985 

Informational 

(Superseded) 

3.23.2.2  Alternative  specifications.  No  other  specifications  are  known. 

3.23.2.3  Standards  deficiencies.  The  most  significant  deficiencies  in  Ada-83  which  have  been 
addressed  by  Ada-95  are  the  inclusion  of  objects  into  the  language,  a  more  robust  treatment  of 
tasking,  more  flexible  response  to  interrupts,  an  explicit  definition  of  higher  mathematical 
functions,  and  the  explicit  inclusion  of  bindings  to  other  languages.  All  documented  deficiencies  in 
the  Ada-83  standard  are  included  in  the  Ada-95  Project  Report,  which  is  available  through  the 
Ada  Information  Clearinghouse. 

3.23.2.4  Portability  caveats.  Within  the  limits  of  the  features  tested  under  the  ACVC,  Ada 
source  code  is  completely  portable  across  all  compilers  and  hardware/operating  system  platforms. 
Portability  problems  will  be  more  likely  to  exist  when  changing  compiler  vendors  than  when 
moving  across  platforms  supported  by  a  single  compiler  vendor.  In  particular,  vendor-to-vendor 
portability  problems  can  result  from  the  use  of  Ada  language  components  which  are  specified  as 
implementation  dependent  (e.g.,  PRAGMAS).  Special  purpose  libraries  (e.g.,  support  for  DOS 
functionality)  also  are  a  major  source  of  portability  problems.  In  general,  automated  source 
translation  software  exists  to  resolve  the  major  portion  of  these  remaining  incompatibilities. 
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Efforts  are  underway  to  increase  the  depth  and  breadth  of  future  releases  of  the  ACVC  so  as  to 
further  reduce  compiler  and  platform  dependencies. 

3.2J.2.5  Related  standards.  SPC-91061-N,  Ada  Quality  and  Style:  Guidelines  for  Professional 
Programmers,  Version  2.01.01, 1991,  is  related  to  Ada.  Similar  to  other  programming  languages, 
Ada  style  guides  are  desirable  for  their  contribution  to  the  quality  and  consistency  of  Ada  code. 
The  AJPO  has  endorsed  this  Software  Productivity  Consortium  (SPC)  publication  as  a  suggested 
Ada  Style  Guide  for  DGD  programs.  This  guide,  available  from  the  Ada  Joint  Program  Office, 
contains  more  information  on  the  handling  of  implementation-dependent  features. 

3 .2 .3.2.6  Recommendr  io  s.  The  use  of  the  Ada  (ANSI/ISO/IEC  8652:  1995,  as  adopted  by 
FIPS  PUB  1 19-1: 1995'  •ogramming  language  (Ada-95)  is  mandated  for  new  procurement. 

(See  section  3.2.3.2  for  details).  Initially,  there  may  be  productivity  limitations  due  to  the  absence 
of  bindings  and  support  tools  for  Ada-95.  Transition  of  software  from  Ada-83  will  not  be  required 
unless  the  availability  of  Ada-83  compilers  becomes  a  problem  or  additional  functionality 
supported  by  Ada-95  is  required  by  the  target  system. 

Implementation-defined  features  and  other  features  which  are  not  standard  to  the  Ada 
programming  language  must  be  avoided.  The  Ada  Quality  and  Style:  Guidelines  f  r  Professional 
Programmers,  available  from  the  AJPO,  contains  more  information  on  the  handling 
ofimplementation-depcndent  features.  This  guideline  can  be  used  as  a  tailoring  reference  for  many 
of  the  areas  discussed  in  the  following  sections  about  Ada. 

Although  upward  compatibility  was  a  major  design  consideration  for  Ada-95,  incompatibilities  are 
likely  betweer  Ada-83  and  Ada-95.  When  considering  the  transition  to  Ada-95,  the  Ada-83 
system  design  and  implementation  should  be  assessed  in  view  of  the  final  documented 
incompatibilities.  Discrepancies  between  Ada-83  and  Ada-95  have  been  identified  and  suggested 
coding  practices  and  source  code  modifications  have  been  identified  and  tested,  allowing 
recompilation  of  existing  Ada-83  code  by  Ada-95  compilers,  information  on  these  coding 
practices  can  be  found  in  the  Ada  Style  Guide  and  the  Ada-95  Project  Report,  both  available  from 
the  AJPO.  A  comprehensive  transition  to  Ada-95  cannot  be  undertaken  until  Ada-95  compilers 
pass  validation  testing. 

Despite  these  limitations,  the  ASD  C3I  in  a  Memorandum  of  9  March  1994,  encourages  early  use 
of  Ada9X  (Ada-95).  The  use  of  available  unvalidated  Ada-95  compilers  is  encouraged. 
Unvalidated  Ada-95  compilers  may  be  used  for: 

a.  Research  and  development  programs  (6. 1 , 6.2,  and  6.3A  appropriations). 

b.  Proof  of  concept  prototypes,  so  long  as  any  subsequent  system  is  delivered  using 
validated  Ada-95  compilers. 

c.  System  development  programs,  so  long  as  the  systems  are  delivered  using 
validated  Ada-95  compilers,  in  accordance  with  the  validation  procedures  issued 
by  the  AJPO. 
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Early  use  of  Ada-95  provides  access  to  the  language's  many  enhancements,  including  full  support 
for  object-oriented  programming,  enhancements  for  realtime  programming,  and  interfacing  to 
other  languages. 

In  systems  where  COTS  software  is  to  be  used  extensively,  the  amount  of  non-COTS  code  to  be 
developed  and  the  interfaces  to  the  COTS  software  need  to  be  considered  when  evaluating  the 
long-term  cost/benefits  of  using  another  HOL  versus  Ada  as  a  development  language.  In  most 
cases,  developing  Ada  links  to  existing  bindings  has  proven  to  be  an  effective  development 
method.  Furthermore,  in  applications  where  concurrent  processing  is  required,  the  inherent 
implementation  of  concurrent  methods  by  Ada  is  preferable  to  another  HOL,  since  concurrent 
processing  in  other  HOLs  is  handled  often  by  invoking  operating  system  calls.  The  concurrency 
methods  in  Ada  are  independent  of  the  operating  system. 
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3 2 3 J  C,  C++.  C  is  a  systems  programming  language  which  has  been  adopted  for  widespread 
use  as  a  general  purpose  language  in  developing  commercial  applications.  C  is  a  relatively  "low 
level"  language  which  deals  with  basic  computer  objects,  such  as  characters,  numbers,  and 
addresses,  and  does  not  inherently  provide  operations  to  deal  with  composite  objects,  such  as 
strings,  sets,  lists.  Library  units  have  been  added  to  the  language  to  partially  support  functionality 
of  such  objects.  ANSI  C  is  strongly  typed  and  is  an  implicitly  integer  language,  i.e.,  untyped 
functions  and  variables  are  assumed  to  be  integer.  The  popularity  of  C  derives  from  its  support  for 
low  level  control  and  interaction  with  peripherals  and  the  operating  system,  the  highly  efficient 
code  which  is  generated  by  modem  C  compilers,  and  the  wide  availability  of  such  compilers. 

C++  is  an  Object-Oriented  Programming  (OOP)  superset  of  the  C  language.  Existing  C  context  is 
fully  supported  by  C++  compilers,  with  additional  support  for  data  abstraction,  encapsulation, 
object  classes,  inheritance  (and  multiple  inheritance),  polymorphism,  and  overloading.  While 
considered  a  general  purpose  language,  its  core  area  of  application  is  systems  programming.  C++ 
was  developed  to  encourage  good  software  engineering  practice  and  the  development  of  reuse 
libraries  in  the  development  of  larger  applications. 

3.2.3.3.1  Standard.  Table  3.2-20  presents  standards  for  C. 


TABLE  3.2-20  C,  C++  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC/IPC 

ANSI/ISO 

Programming  Language*:  C 

9899:1992 

Adopted 

(Approved) 

GPC 

NIST 

C  (Adopt*  ANSI/ISO/IEC  9899:1992) 

FIPS  PUB 
160:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

C,  Amendment  1:  Integrity  Addendum 

9899:1994  PDAM 

Informational 

(Draft) 

IPC 

ISO/IEC 

C++ 

SC22  WG22, 
X3J16 

Informational  Q 

(Draft)  I 

3.2.3.3.2  Alternative  specification.  The  original  definition  of  the  C  language  by  Kemighan  & 
Ritchie  (K&R)  is  considered  by  many  as  "THE"  specification  of  the  C  language.  This  specification 
is  NOT  coincident  with  the  ANSI/ISO/IEC  standard. 

3.2.3.3.3  Standard  deficiencies.  While  there  is  an  existing  ISO  standard  for  the  C  language  that 
supports  and  is  supported  by  the  IEEE  1003.1  C  Language  Binding  to  POSIX,  the  intrinsically 
low  level  nature  of  C  and  lack  of  direct  support  for  modern  software  engineering  approaches  and 
discipline  make  it  an  undesirable  language  for  the  development  of  large,  general  purpose  DoD 
software  applications.  C  can  offer  benefits  when  used  specifically  for  systems  level  programming, 
when  required  for  especially  compact  or  efficient  code,  or  when  used  at  an  interfacing  level  where 
direct  bindings  to  high  level  languages  do  not  exist.  The  use  of  C  in  general  purpose  applications 
is  often  justified  by  a  large  population  of  "trained"  C  programmers;  however,  useful  C  code  on 
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large  projects  can  only  be  developed  by  those  few,  highly  self-disciplined,  virtuoso,  software 
engineers. 

C++  is  an  emerging  language  with  no  current  standard,  although  AT&T's  Bell  Labs,  where  the 
language  originated  and  where  development  has  continued,  have  produced  defining 
documentation  for  the  language,  including  The  C++  Programming  Language  by  Bjame 
Stroustrup,  one  of  the  principal  developers  of  die  language.  The  lack  of  a  current  compiler 
standard  makes  C++  source  code  portability  problematic.  This  is  further  complicated  by  the 
current  popularity  of  C++  in  the  development  of  Graphical  User  Interface  (GUI)  based 
applications,  which  rely  heavily  on  compiler  vendor-specific  interface  libraries.  Because  the 
mechanics  of  the  C  language  are  embedded  in  C++,  it  is  susceptible  to  many  of  the  above  noted 
difficulties  with  C,  despite  the  introduction  of  OOP  software  engineering  into  the  language. 

3.2.3J.4  Portability  caveats.  Differences  between  ANSI  C  and  K&R  C  can  be  significant  and 
can  affect  portability.  Furthermore,  the  lack  of  a  current  compiler  standard  makes  C++  source 
code  portability  problematic. 

323.3 £  Related  standards.  No  related  standards  to  C  or  C++  are  known. 

3.23.3.6  Recommendations.  ANSI/ISO/IEC  9899:1992  and  FIPS  PUB  160:1992  are  the 
recommended  standards  for  legacy  systems  written  in  C  and  C++  languages.  Use  of  C++  for  the 
development  of  critical  systems  applications  is  not  recommended. 
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3 2  J.4  FORTRAN.  FORTRAN,  which  is  an  acronym  for  FORMula  TRAN slating  system,  is  a 
programming  language  originated  in  1954  and  designed  to  sup’-  irt  scientific  and  engineering 
applications  requiring  calculation-intense  computing.  FORTRAN  is  the  oldest  surviving  HOL  and 
existing  applications  may  have  been  developed  in  several  diale  ;  of  the  language:  FORTRAN  IV 
dates  to  1962  and  was  standardized  in  1966  (sometimes  called  FORTRAN  66)  due  to  the  large 
number  of  non-portable  variants  of  FORTRAN  IV  which  had  been  developed;  FORTRAN  77  was 
a  major  extension  to  FORTRAN  which  introduced  C  and  Pascal  control  structures  into  the 
language  to  limit  the  FORTRAN  "spaghetti  code"  problem;  and  FORTRAN  90  is  a  further 
extension  to  the  language  to  include  flexible,  modem  data  struc*ures  into  FORTRAN.  Most 
FORTRAN  legacy  programs  have  been  developed  under  FORTRAN  IV  and  FORTRAN  77. 
FORTRAN  90  has  not  gained  wide  spread  acceptance  within  the  FORTRAN  programming 
community. 

FORTRAN  supports  data  typing  by  providing  primarily  numeric  data  types  (INTEGER,  REAL, 
DOUBLE  PRECISION,  COMPLEX),  LOGICAL,  and  CHARACTER  to  support  characters  and 
strings  (as  arrays  of  CHARACTERS).  Through  FORTRAN  77,  <uTays  were  the  only  composite 
data  tyne  supported.  More  advanced  data  types  are  supported  in  the  FORTRAN  90  standard. 
FORTRAN  77  does  not  support  dynamic  data  structures  or  address  pointers.  I/O  library  by 
FORTRAN  includes  extensive  I/O  capabilities  explicitly  in  the  ('■  finition  of  the  language. 
Additionally,  a  standard  defining  a  FORTRAN  77  binding  to  POSIX  has  been  developed  by  the 
IEEE  as  the  1003.9  standard.  FORTRAN  has  explicit  support  fcv  high  level  mathematical 
functionality,  unlike  C  and  Ada,  where  mathematical  library  units  are  defined  externally  to  the 
base  language.  Basic  logical  operations  are  fully  supported  in  1  DRTRAN.  The  LOGICAL  type  is 
functionally  equivalent  to  the  Boolean  type  in  Ada.  The  "ELSE"  construct  was  not  supported  in 
FORTRAN  prior  to  FORTRAN  77.  A  CASE  or  SWITCH  logical  control  mechanism  is  not 
supported  in  FORTRAN.  Fixed  ’point  arithmetic  is  not  explicitly  supported  in  FORTRAN. 

Floating  point  is  supported  though  the  REAL  ,\nd  DOUBLE  PRECISION  types.  FORTRAN 
supports  implicit  typing  of  REAL,  and  INTEGER  variables.  Timing  functionality,  either  simple  or 
for  concurrent  operation,  is  not  supported  by  FORTRAN.  FOR  .RAN  contains  no  object-oriented 
capabilities,  though  work  in  this  area  is  being  pursued  by  ANSI. 

FORTRAN  is  included  in  the  ITSG  discussion  of  programming  languages  in  deference  to  the 
large  amount  of  available  legacy  engineering  and  scientific  sc  ’  e  written  in  the  language. 

3.2.3.4.1  Standards.  Table  3.2-21  presents  standards  for  FOh  \N. 


TABLE  3.2-21  FORTRAN  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI 

FORTRAN -90 

X3. 198- 1992 

Adopted 

(Approved) 

IPC 

ISO 

FORTRAN-90 

1539:1991 

Adopted 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

FORTRAN-77  («Jopu  ANSI  X3.9) 

FIPS  PUB  69-1: 
1985 

Adopted 

(Approved) 

NPC 

ANSI 

FORTRAN-77 

X3.9-1978  (R 1989) 

Adopted 

(Approved) 

NPC 

ANSI 

Object  FORTRAN 

TBD 

Iofonnatxxukl 

(TBD) 

3.2. 3.4.2  Alternative  specifications.  The  so-called  "VAX  Extensions"  to  FORTRAN  77  are 
widely  supported.  The  IBM  Systems  Application  Architecture  (SAA)  FORTRAN  binding  to 
SQL  is  also  available,  but  is  proprietary. 

32.3.43  Standards  deficiencies.  FORTRAN  90  has  not  gained  widespread  acceptance  in  the 
FORTRAN  programming  community.  Vendors  have  selectively  implemented  FORTRAN  90 
attributes  into  their  compilers.  The  few  existing  FORTRAN  bindings  to  OSE  component  sub¬ 
systems  are  based  upon  FORTRAN  77.  FORTRAN  77  does  not  supply  a  fully  modem  set  of  data 
types,  control  statements,  and  modularity  support.  In  FORTRAN,  the  EQUIVALENCE 
statement  can  be  used  to  break  explicit  typing  of  data. 

Because  of  the  nature  of  the  language,  the  IEEE  1003.9  specification  of  the  FORTRAN  binding 
to  POSIX  is  less  stringent  and  more  vendor  and  implementation  dependent  than  IEEE  1003. 1  and 
1003.5  (C  and  Ada  bindings,  respectively). 

3.2.3.4.4  Portability  caveats.  Older  versions  of  FORTRAN,  particularly  FORTRAN  IV,  exhibit 
many  portability  problems,  hence,  the  advent  of  FORTRAN  77.  Legacy  software  written  in 
versions  of  FORTRAN  earlier  than  FORTRAN  77  can  be  expected  to  be  difficult  to  port  between 
platforms  or  operating  systems.  Modem  compilers  have  been  selective  in  "choosing"  features  of 
FORTRAN  90  to  implement.  This  can  cause  obvious  portability  difficulties. 

Numeric  precision  of  REAL  and  DOUBLE  PRECISION  data  types  has  been  a  historical  trouble 
spot  for  porting  of  FORTRAN  source  code  between  platforms.  The  FORTRAN  77  standard 
addresses  this  problem.  However,  older  FORTRAN  IV  applications  may  still  exhibit  these 
problems. 

The  use  of  special  features  for  I/O,  such  as  I/O  handling  features  specific  to  the  hardware, 
compiler  or  operating  system,  can  lead  to  portability  problems.  FORTRAN  IV  legacy  software 
can  contain  OS  specific  I/O. 

Portability  of  FORTRAN  across  different  operating  system  and  hardware  suites  is  subject  to 
errors  brought  about  by  differences  between  FORTRAN  compiler  implementations  and 
hardware/operating  system  internal  numerical  representations. 
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323 AS  Related  standards.  Other  than  the  standards  referenced  above,  there  are  no  other 
standards  applicable  to  FORTRAN  for  compiler  or  user-defined  data  typing.  The  only  standard 
related  to  math  functions  is  the  IEEE  754  floating  point  standard. 

S.2.3.4.6  Recommendations.  IS01539:199 1/ANSI  X3.198:1992  and  NIST  FIPS  PUB 
69-1/ANSI  X3.9:1978  (R1989)  are  the  recommended  standards  for  FORTRAN-based  legacy 
systems.  NIST  FIPS  PUB  69-1  is  the  recommended  standard  for  legacy  FORTRAN  development 
FORTRAN  has  been  used  traditionally  for  scientific  processing.  Although  FORTRAN-90 
contains  added  capability  over  FORTRAN-77,  it  does  not  contain  any  capabilities  making  it 
preferable  to  Ada  for  DOD  applications.  FORTRAN  should  not  be  chosen  for  the  development  of 
new  DOD  applications  and  should  be  used  only  to  maintain  legacy  software.  VO  based  on  the 
IEEE  1003.9  specified  library  is  preferred  for  OSE  systems. 
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3.2.3.5  COBOL.  COBOL,  an  acronym  for  COmmon  Business  Oriented  Language,  is  a 
programming  language  for  use  in  financial  and  accounting  applications.  Created  during  the  early 
60s,  COBOL  is  the  most  widely  used  language  for  data  processing  applications  and  has  an 
extensive  software  legacy.  It  was  intended  as  a  design  for  a  common  language  that  would  enable 
programs  and  programming  techniques  to  be  easily  shared  and  transferred  between  machines. 
Despite  this  design  goal,  COBOL  programs  are  verbose  and  not  truly  self  documenting,  and  are 
difficult  to  maintain  and  tend  toward  "bugginess."  COBOL  is  strictly  for  data  processing 
applications  and  has  no  role  as  a  more  general  language. 

Only  two  types  of  variables  are  recognized  by  COBOL,  numeric  and  non-numeric.  Arrays  and 
records  are  supported  via  the  COBOL  table  and  record  description  entry  constructs.  Dynamic 
structures  are  not  supported.  COBOL  has  a  strong  set  of  file  manipulation  functions  for  data 
processing  applications.  These  functions  are  intrinsic  to  the  language.  COBOL  supplies  a  minimal 
set  of  logical  and  mathematical  operations.  No  advanced  mathematical  functions  are  supported. 
Logical  variables  are  supported  in  COBOL  via  testable  conditions.  IF  -  ELSE  control  and 
relational  test  operators  are  supplied.  Basic  mathematical  operations  to  support  financial 
calculations  are  supported  by  COBOL.  COBOL  is  not  a  real  time  language.  It  supports  neither 
simple  nor  complex  (e.g.,  concurrent)  timing  functionality.  COBOL  contains  no  object-oriented 
capabilities,  though  work  in  this  area  is  being  pursued  by  ANSI. 

3.2J.5.1  Standards.  Table  3.2-22  presents  standards  for  COBOL. 


TABLE  3.2-22  COBOL  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

COBOL  (adopti  ANSI  X3.23*  1989  and  X3.23b:  1993) 

FIPS  PUB  21- 

4:1995 

Adopted 

(Approved) 

[PC 

ISO 

COBOL 

1989:1985 

Adopted 

(Approved) 

NPC 

ANSI 

COBOL 

X3.  23:  1985 

Adopted 

(Approved) 

NPC 

ANSI 

COBOL 

X3.  23*  1989 

Informational 

(Approved) 

NPC 

ANSI 

COBOL 

X3.  23:  1993 

Inform  ational 
(Approved) 

j  NPC 

ANSI 

Object  COBOL 

TBD 

Informational  I 
(Formal!  ve) 

3.2.3.5.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.3.5.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.3.5.4  Portability  caveats.  The  COBOL  language  has  a  design  goal  of  transparent  portability 
of  data  across  platforms.  Portability  of  COBOL  across  different  operating  system  and  hardware 
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suites  is  subject  to  errors  brought  about  by  differences  between  COBOL  compiler 
implementations  and  hardware/operating  system  internal  numerical  representations. 

3-2J.5.5  Related  standards.  The  emerging  standard  for  Object  COBOL  is  referenced  in  the  table 
above. 

3J.3J.6  Recommendations.  NIST  FIPS  PUB  21-4/ISO  1989/ANSI  X3.23  are  the 
recommended  standards  for  COBOL.  COBOL  should  be  included  in  an  OSE  only  to  maintain 
legacy  software.  However,  Ada  has  been  shown  to  be  effective  in  these  applications  as  well  as  less 
costly  to  maintain  than  existing  COBOL  software.  Furthermore,  Ada  includes  features,  such  as 
fixed  point  arithmetic,  that  have  been  identified  as  the  cause  of  usability  and  portability  problems 
in  COBOL  legacy  applications.  The  reengineering  of  COBOL  programs  to  Ada  has  been  proven 
to  be  more  cost-effective  than  maintaining  the  existing  systems  in  the  long  term. 
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3.23.6  JOVIAL.  JOVIAL  (Jules'  Own  Version  of  the  International  Algebraic  Language)  is  an 
ALGOL-like  scientific  and  engineering  programming  language  developed  by  Jules  Schwartz  of 
Systems  Development  Corp.  for  the  USAF  in  the  1960s.  JOVIAL  was  the  Air  Force's  solution  to 
the  need  for  a  better  structured  and  more  stable  mathematical  language  than  FORTRAN  long 
before  the  advent  of  Ada.  JOVIAL  includes  unique  data  types  for  expressing  real  values. 

3.23.6.1  Standards.  Table  3.2-23  presents  standards  for  JOVIAL. 


TABLE  33-23  JOVIAL  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD  (USAF) 

JOVIAL  (J73) 

MIL-STD-I589C: 

1996 

Adopted 

(Approved) 

3.23.6.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.3.63  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.23.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  specification  are 
unknown. 

3.23.6.5  Related  standards.  No  other  specifications  are  known. 

3.23.6.6  Recommendations.  MIL-STD-1589C  is  the  recommended  standard  for  JOVIAL  based 
legacy  systems  and  software.  JOVIAL  has  been  used  traditionally  for  real  time  and  scientific 
processing.  The  availability  of  Ada  compilers  and  cross-compilers  make  Ada  a  cost-effective 
alternative.  In  fact,  the  USAF  has  undertaken  a  policy  of  converting  all  useful,  existing  JOVIAL 
software  into  Ada. 
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3.2.3.7  MUMPS.  MUMPS  (Massachusetts  General  Hospital  Utility  Multiprogramming  System) 
is  an  advanced,  high-level  programming  language  and  integrated  database  used  for  business 
applications.  It  has  extensive  string  handling  functionality,  making  it  suitable  for  databases  with 
large  text  entries.  MUMPS,  renamed  M  during  1993,  has  been  widely  used  for  the  computing 
needs  of  the  medical  community.  Two  major  federal  systems  implemented  with  MUMPS  are  the 
Veterans  Affairs'  Decentralized  Hospital  Computer  Program  (DHCP)  and  the  DOD  Composite 
Health  Care  System  (CHCS).  MUMPS  originated  in  1965  and  is  based  upon  the  127  ASCII 
characters.  MUMPS  adopts  ANSI/MDC  XI  1.1-1995  and  is  currently  being  revised.  A  MUMPS 
validation  suite  is  available  from  NTTS. 

3.2 .3.7.1  Standards.  Table  3.2-24  presents  standards  for  MUMPS. 


TABLE  3.2-24  MUMPS  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

MUMPS  (Adopu  ANSI/MDC  XI  1.1- 1990) 

FIPS  PUB  125- 
1:1993 

Adopted 

(Approved) 

NPC 

ANSI/MDC 

MUMPS 

XII.  1-1995 

Informational 

(Approved) 

3.2.3.7.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.3.7.'1  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.3.7.4  Portability  caveats.  The  MUMPS  language  is  supported  on  a  limited  number  of 
platform/operating  system  combinations. 

3.2.3.7.5  Related  standards.  No  other  specifications  are  known. 

3.2.3.7.6  Recommendations.  The  FIPS  PUB  125-1  standard  is  recommended  for  MUMPS  based 
legacy  systems  and  software.  MUMPS  provides  unique  large  record  length  database  capabilities 
not  found  in  other  languages.  However,  currently  underway  is  a  development  activity  to  provide  a 
library  of  Ada  units  which  can  supply  MUMPS  like  functionality  to  software  developed  in  Ada. 
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3 .2.3.8  Simulation  languages.  Simulation  is  the  representation  of  selected  characteristics  of  the 
behavior  of  one  physical  or  abstract  system  by  another  system.  In  a  digital  computer  system, 
simulation  i  done  by  software;  for  example,  the  representation  of  physical  phenomena  by  means 
of  operatio  .s  performed  by  a  computer  system  or  the  representation  of  operations  of  a  computer 
system  by  those  of  another  computer  system. 

3.23.8.1  Standards.  Table  3.2-25  presents  standards  for  simulation  langauges. 


TABLE  3.2-2S  Simulation  languages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mml 

TBD 

TBD 

GPSS 

TBD-GPSS 

Informational 

(TBD) 

TBD 

TBD 

Simacript 

TBD-Sinucript 

Informational 

(TBD) 

TBD 

TBD 

Simula 

TBD- Simula 

Informational 

(TBD) 

3.2.3.8.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.3.8J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.3.8.4  Portability  caveats.  No  portability  of  code  can  be  assumed  in  the  use  of  these  existing 
specialty  simulation  languages. 

3.2.3.8.5  Related  standards.  No  other  specifications  are  known. 

3.2.3.8.6  Recommendations.  No  standards  are  recommended  for  simulation  languages.  Special 
simulation  languages  allow  for  rapid  prototyping  and  development  of  quick  use  simulation  tools. 
Generally  such  software  is  not  readily  maintainable.  Use  should  be  limited  to  proof  of  concept 
rapid  prototyping,  novel  algorithm  development  and  demonstration,  and  limited  use  simulations 
which  require  an  extremely  short  development  cycle.  Major  simulation  efforts  which  require  a 
high  order  language  should  be  implemented  in  Ada. 
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3 .2.3.9  Artificial  intelligence  languages.  Artificial  Intelligence  (Al)  languages  are  a  subfield 
within  computer  science  concerned  with  developing  a  technology  to  enable  computers  to  solve 
problems  (or  assist  humans  in  solving  problems).  The  LISP  (LISt  Processing)  language  is  the 
most  popular  one  for  research  in  AI.  LISP  is  a  high-level,  non-numeric  language  with  the 
syntactic  distinction  that  there  is  no  difference  between  the  treatment  of  data  and  instructions. 
LISP  was  developed  in  1960  and  its  current,  standardized  version  is  referred  to  as  Common  LISP. 

3.2.3.9.1  Standards.  Table  3.2-26  presents  standards  for  artificial  intelligence  languages. 


TABLE  3.2-26  Artificial  intelligence  languages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

min 

CPC 

X/Op«i 

PROLOG 

TBD- PROLOG 

Informational 

(Draft) 

NPC 

ANSI/X3J13 

Common  LISP  (X3.226  Programming  Language  Common 

LISP) 

X3J 13/92- 101 

Informational 

(Draft) 

NPC 

IEEE 

AI-ESTATE 

SC  20,  PAR  1232 

Informational 
(Draft  (CD)) 

NPC 

ANSI 

Common  LISP  Object  Sytlem  (CLOS) 

TBD 

Informational 
(Draft  (CD)) 

NPC 

rHPE 

Interoperability  of  Knowledge- Baaed  Systems 

TBD- 

Inleropenbtlity  of 

Knowledgo-Based 

Systems 

Informational 

(Formative) 

3.2.3.9.2  Alternative  specifications.  No  other  specifications  are  known. 

3.2.3.9.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown.  Currently 
standards  are  being  developed  for  Common  LISP  and  PROLOG.  Common  LISP  is  more  popular 
in  the  United  States  and  PROLOG  is  more  popular  in  England  and  Europe,  posing  potential 
interoperability  problems. 

3.2.3.9.4  Portability  caveats.  No  portability  of  software  written  with  these  languages  can  be 
guaranteed. 

3.2.3.9.5  Related  standards.  No  other  specifications  are  known. 

3.2.3.9.6  Recommendations.  No  standards  are  recommended  for  artificial  language  standards. 
The  current  generation  of  artificial  intelligence  languages  are  laboratory  tools  useful  in  the  study 
of  AI  concepts.  Generally  such  software  is  not  readily  maintainable.  Use  should  be  limited  to 
proof  of  concept  rapid  prototyping,  novel  algorithm  development  and  demonstration,  and  general 
AI  research  activities. 


April  7,  1997 


3.2-52 


Version  3. 1 


Information  Technolog v  Standards  Guidance 


Software  Engineering  Services 


3.2.3.10  Fourth  generation  languages.  Fourth  generation  languages  (4GLs)  are  designed  to 
improve  the  productivity  achieved  by  HOL  (third  generation)  languages  and  to  make  computing 
power  available  to  non-programmers.  Features  typically  include  an  integrated  database 
management  system,  query  language,  report  generator,  and  screen  definition  facility.  Addition 
features  support  function,  financial  modeling,  spreadsheet  capability,  and  statistical  analysis 
functions. 

3.23.10.1  Standards.  Table  3.2-27  presents  standards  for  fourth  generation  languages. 


TABLE  32-27  Fourth  generation  languages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

fljfl 

N/A 

N.A. 

Nooe 

N.A. 

Information*! 

(N.A.) 

3.2.3.10.2  Alternative  specifications.  The  only  available  specifications  are  proprietary. 

3.2.3.103  Standards  deficiencies.  All  4GLs  are  proprietary.  Therefore,  4GLs  have  not  been 
standardized,  and  creation  of  a  4GL  standard  is  not  planned.  Furthermore,  4GLs  often  lack  the 
functionality  to  define  a  complete  system  within  their  specification  language.  They  are  not 
integrated,  making  them  incapable  of  linking  the  various  parts  of  the  system.  They  make 
inefficient  use  of  machine  resources,  and  are  very  expensive  in  terms  of  hardware  requirements 
and/or  software  license  fees. 

3.23.10.4  Portability  caveats.  Portability  problems  relating  to  the  existing  specification  are 
unknown. 

3.23.103  Related  standards.  The  ANSI/ISO/IEC  9075-1992  standard,  Database  Languages  - 
SQL,  is  related  to  4GLs. 

3.2.3.10.6  Recommendations.  No  standards  are  recommended  for  4GLs.  Implementation- 
defined  features  and  other  nonstandard  features  of  the  programming  language  must  be  avoided. 
The  4GL  situation  is  improving.  For  example,  AdaSAGE  was  developed  for  the  government  to 
provide  tools  and  an  environment  for  Ada  programmers  to  develop  major  nonproprietary  systems 
completely  in  Ada. 
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3.2.4  Bindings.  Language  bindings  are  interfaces  to  operating  systems,  network  software, 
graphical  user  interfaces,  database  management  systems,  and  other  system  software  specific  to  a 
programming  language.  Bindings  define  conventions  for  accessing  functionality  of  the  specified 
sub-system.  Calling  conventions  include  the  name  of  the  functional  service  called,  the  arguments 
to  be  included  in  the  call,  the  data  type  of  these  arguments,  the  order  of  the  arguments,  error 
conditions  which  may  result,  and  returned  values.  Because  of  the  extensive  lists  of  available 
bindings  for  some  languages,  cnly  a  small  subset  of  the  available  'bindings  will  be  listed  for  each 
language.  References  to  complete  listings  of  bindings  for  each  L  ■  "uage  are  included. 

3.2.4.1  Ada  bindings.  Few  Ada  bindings  currently  are  implemented,  although  many  standards 
exist  or  are  in  development  for  Ada  bindings  to  OSE  component  sub-systems.  Due  to  the 
importance  of  the  Ada  language,  many  working  group  ,  are  active  in  the  development  of 
specifications  for  mrny  such  bindings. 

3.2.4.1.1  Standards.  Tabic  3.2-28  presents  standards  for  Ada  bindings. 


TABLE  3.2-28  Ada  bindings  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

TFKE 

1003.5:1992 

Adopted 

(Approved) 

IPC 

ISO 

Datable  Language  SQL  (»ame  u  ANSI  X3. 135- 1992) 

9075:1992 

Adopted 

(Approved) 

[PC 

ISO/IEC 

Ada  Binding*  of  PHIGS  (binding  for  Ada-83) 

9593-3:1990 

Adopted 

(Approved) 

GPC 

NIST 

PH1GS  language  bindings  -  Part  3:  Ada  (binding  for  Ada- 
83) 

FIPS  PUB 
153:1992 

Adopted 

(Approved) 

NPC 

ANSI 

SQL  Ada  Module  Extension*  (SAME)  (binding  for  Ada- 

83) 

X3. 168- 1989 

Adopted 

(Approved) 

NPCAjPC 

ANSI/NIST 

SQL  and  Ada  Binding*  (ANSI  X3. 135: 1992)  (binding  for 
Ada-83) 

X3. 135: 1992  FIPS 
127-2:1993 

Adopted 

(Approved) 

[pc 

ISO 

9638-3:1994 

Adopted 

(Approved) 

IPC 

ISO/IEC 

SQL  Ada  Module  Description  Language  (SAMeDL),  First 
Edition 

12227:1995 

Adopted 

(Approved) 

IPC 

ECMA 

Portable  Common  Tool  Environment  (PC' It)  -  Ada 
Programming  Language  Binding 

162(1991) 

Informational 

(Approved) 

ire 

ISO 

Graphical  Kernel  System  for  Three  Dimensions  (GKS-3D) 
language  bindings  -  it  3:  Ada  (binding  for  Ada-83) 

8806-3:1988 

Informational 

(Approved) 

GPC 

DOD 

STARS 

Informational 

(Approved) 

[PC 

ECMA 

PCTE  -  Extensions  for  Support  of  Fine-Grain  Objects  -  Ada 
Programming  Language  Binding 

229  (1995) 

Informational 

(Approved) 

NPC 

ANSI 

GKS  Language  Bindings  for  Ada 

X3. 124.3- 1989 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

GKS  Language  Bindings  •  Part  3:  Ada 

8651-3:1988 

Informational 

(Approved) 

OPC 

NIST 

GKS  Bindings  for  Ada 

FIPS  PUB  120- 
1:1994 

Informational 

(Approved) 

NPC 

EPEE 

POSIX  Ada  Language  Interfaces  -  Part  1  :  Binding  for 
Realtime  Extensions 

1003.5b:  1996 
(former  1003 JO) 

Informational 

(Approved) 

IPC 

ISO/IEC 

PHI  CIS  PLUS/Ada  binding  *  (bindm*  for  Ada-83) 

9593-3  PDAM I 

Informational 

(Draft) 

IPC 

ISO 

Generic  Package  of  Elementary  Pmctkxu  (GPEF)  (binding 
for  Ada-83) 

TBD- Generic 
Package  of 
Elementary 
Functions  (GPEF) 
(binding  for  Ada- 
83) 

Informational 

(Draft) 

NPC 

IFKE 

POSIX  -  Part  1:  Syrian  API  Amendment:  Real-Time 
Distributed  Syitemi  Communications 

PI003.21 

Informational 

(Draft) 

IPC 

ISO 

Ada  Europe  Numerics  Working  Group  Primitive  Funcboru 
(binding  for  Ada-83) 

TBD- Ada  Europe 
Numerics  Working 
Group  Primitive 
Functions  (binding 
for  Ada-83) 

Informational 

(Draft) 

TBD 

TBD 

Ada  Semantic  Interface  Specificatioo  (ASIS)  (binding  is 
planned  for  approval  on  the  summer  ri  95) 

TBD- Ada  Semantic 
Interface 
Specification 

(ASIS)  (binding  is 
planned  for 
approval  on  the 
summer  of  95 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface  Amendment  2:  Ada  bindings  (binding  for  Ada-83) 

10728  WDAM 
2:1993 (E) 

Informational 

(Draft) 

GPC 

NIST 

Initial  Graphics  Exchange  Specification  GOES);  v.  5.2  OR 
6.0 

FIPS  PUB  177-1 
(future) 

Informational 

(Formative) 

NPC 

IRHP. 

P120I.I 

Informational 

(Formative) 

NPC 

IEEE 

Ada  binding  to  P1003.2  (binding  for  Ada-83) 

TBD- Ada  binding 
to  P 1003.2  (binding 
for  Ada-83) 

Informational 

(Formative) 

NPC 

EIA 

CASE  Data  Interchange  Formal  (CDG7)  Ada  bindings 
(binding  for  Ada-83) 

TBD 

Informational 

(Formative) 

TBD 

TBD 

Standard  Generalized  Markup  Language  (SGML)  Ada 
bindings 

TBD- Standard 
Generalized 
Markup  Language 
(SGML)  Ada 
bindings 

Informational 

(Formative) 

TBD 

TBD 

Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  j 
Ada  bindings  (binding  for  Ada-83) 

TBD-Transmission 

Control 

Protocol/Intemet 
Protocol  (TCP/IP) 
Ada  bindings 
(binding  for  Ada- 
83) 

Informational 

(Formative) 

IPC 

ISO/IEC 

X.25  Ada  bindings  (binding  for  Ada-83) 

X.25  Ada  bindings 

(binding  for  Ada- 
83)  ! 

Informational 

(Formative) 

TBD 

TBD 

Generic  Package  of  Primitive  Functions  (GPPF)  (binding  i 
for  Ada-83) 

TBD-Generic  | 
Package  of  i 

Primitive  Functions  | 

(GPPF)  (binding  for  ! 

Informational 

(TBD) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

Ad*83) 

NPC 

ANSVASME 

DixiuJ  R**>reaeototice  for  Communkafion  of  Product 
Definition  P*a 

Y14.26MU989 

Inform  afiornl 
(Supeneded) 

3.2.4.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Rational  Systems:  X  Windows  Xlib  implementation. 

b.  U.S.  Army  HQ  Communications-Electronics  Command  (CECOM),  Center  for 
Software  Engineering,  report  on  "Thin"  Ada  Binding  to  P1003.4  describes  a 
possible  Ada-language  interface  with  the  proposed  IEEE  P1003.4  reel  time 
standard. 

3 2.4.13  Standards  deficiencies.  Most  bindings  standards  are  still  incomplete  and  Ada  bindings 
are  needed  for  many  standards.  No  formal  standards  or  specifications  for  bindings  exist  between 
Ada  and  any  graphical  user  interface.  However,  the  USAF  STARS  program  has  developed  an 
Ada  binding  for  Xlib  and  the  Xt  Intrinsics. 

The  IEEE  P1003.5  Group  has  defined  an  Ada  binding  to  the  POSIX  operating  system  kernel 
which  parallels  the  IEEE  1003.1  C  binding.  This  binding  does  not  include  functionality  similar  to 
the  IEEE  1003.2  POSIX  C  binding  standard  for  Shell  and  Utilities.  The  IEEE  P1003.20  Group, 
which  is  defining  Ada  bindings  for  the  POSDC.4  real  time  extensions,  was  formed  in  July  1992. 

Few  or  no  Ada  bindings  are  defined  for  other  IMS  sub-systems. 

No  open  standards  or  de  facto  specifications  exist  for  a  common,  GUI-independent  Interactive 
Design  Tools  Interchange  Format  (IDTIF)  (e.g„  Motifs  User  Interface  Language  (U1L)  and  Sun 
Microsystems'  DEVGUIDE),  that  would  allow  different  tools  for  developing  interactive, 
graphical,  windowing  applications  to  exchange  graphics  objects  and  basic  screen  information. 
Work  in  this  area  is  in  progress  in  the  Open  Software  Foundation's  (OSFs)  User  Interface 
Management  Services  (UIMS)  working  group  and  as  a  part  of  X/Open's  GUI  research.  Presently, 
few  Interactive  Design  Tool  products  are  available.  Those  that  exist  are  just  maturing  and 
generally  do  not  work  with  other  tools. 

Language  bindings  for  character-oriented  GUIs  (i.e„  the  display,  manipulation,  and  management 
of  objects  in  windows  on  a  character-oriented  (non-bit-mapped)  screen)  are  needed. 

3.2.4.1.4  Portability  caveats,  it  is  possible  to  implement  the  X  Window  system  in  Ada,  but  this  is 
a  substantial  amount  of  work.  Some  proprietary  4GL  GUI  builder  products  claim  to  have  direct 
Ada  bindings  to  Motif.  Ada  code  can  interface  with  the  X  libraries,  which  are  written  in  C,  but  the 
Ada  and  C  progranmung  languages  have  fundamental  incompatibilities.  A  number  of  COTS 
products  support  or  supply  such  bindings. 
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33.4.1  J  Related  standards.  No  other  specifications  are  known. 

3.2.4. 1.6  Recommendations.  The  standards  identified  as  adopted  should  be  selected  as  needed. 
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3.2.4.2  C  language  bindings.  C  has  been  die  language  of  choice  among  commercial  software 
developers  over  the  past  decade  for  the  development  of  interface  bindings  for  SQL, 
communications,  windowing  systems,  and  operating  systems.  This  "choice"  has  been  formalized 
by  the  explicit  generation  of  C  binding  standards  for  the  various  aspects  of  POSIX.  Other 
languages  which  must  interface  to  these  support  areas  often  are  written  with  a  library  layer  which 
binds  to  an  existing  C  interface  library.  C++  is  emerging  as  the  language  of  choice  among 
commercial  developers  for  GUI  based  applications. 

3.2.4.2.2  Standards.  Table  3.2-29  presents  standards  for  C  language  bindings. 


TABLE  3.2-29  C  language  bindings  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Graphical  Kernel  System  for  3  Dimensions  (GKS-3D) 
Language  Bindings ,  Part  4:  C 

8806-4:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

PHIGS  Language  Binding,  Fait  4:  C 

9593-4:1991 

Informational 

(Approved) 

NPC 

TFPP. 

1327:1993 

Informational 

(Approved' 

NPC 

IFFF 

X.400- Baaed  Electronic  Messaging  C  Language  Interfaces 
-  Binding  for  API 

1327.1:1993 

Informational 

(Approved) 

NPC 

TFPF. 

Directory  Services  C  Languages  Interfaces  •  Binding  for 
API 

1327.2:1993 

Informational 

(Approved) 

IPC 

ECMA 

Portable  Common  Tool  Environment  (PCTE)  -  C 
Programming  Language  Binding 

158  (1994) 

Informational 

(Approved) 

IPC 

ECMA 

PCTE  -  Extensions  for  Support  of  Fine-Grain  Objects  -  C 
Programming  Language  Binding 

228  (1995) 

Informational 

(Approved) 

GPC 

NIST 

mm 

Informational 

(Approved) 

IPC 

iso/mc 

Portable  Operating  System  Interface  (POSIX)  Part  1 : 
System  API  (Replaces  ISO  9945- 1 : 1990  and  incorporates 
IEEE  1003.1b,  1003.1c,  and  1003.  li) 

9945-1:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface 

10728:1993 

Informational 

(Approved) 

IPC 

ISO 

Portable  Common  Tool  Environment  (PCTE)  -  Part  2:  C 
Programming  Language  Binding 

13719-2:1995 

Informational 

(Approved) 

IPC 

ISO 

GKS  Language  Bindings  -  Part  3:  Ada 

8651-3:1988 

Informational 

(Approved) 

NPC 

IEEE 

OSI  Application  Program  Interface  (API)  -  ACE  and 
Presentation  Layer  API  [C  Binding) 

PI  352 

Informational 

(Draft) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPt)  API  Language 
Bindings,  Part  4:  C 

CD  12087-4: 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface  Amendment  1:  C  Language  Binding 

10728  AMD 
1:1994 

Informational 

(Draft) 

IPC 

ISO/IEC 

9945-1:1990 

Informational 

(Superseded) 
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32A2A  Alternative  specifications.  The  SAA's  SQL  bindings  to  C  are  also  available. 

3 2A.1&  Standards  deficiencies.  Many  standards  lack  a  C  binding,  even  in  draft  form,  although 
more  standards  support  C  bindings  than  any  other  language. 

3J.4.2.6  Portability  caveats.  Portability  problems  related  to  the  existing  bindings  are  unknown. 
3 2A.2.7  Related  standards.  Other  related  standards  are  unknown. 

3.2.4.2.8  Recommendations.  No  standards  are  recommended  for  C  Bindings.  C  bindings  should 
be  used  only  in  the  absence  of  an  equivalent  Ada  binding.  A  layered  Ada-to-C  binding  approach 
should  be  taken  to  allow  rapid  migration  to  the  Ada  binding  when  it  becomes  available. 
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3 2.4.3  FORTRAN  bindings.  FORTRAN,  because  of  its  historic  usefulness  and  popularity,  has 
been  the  subject  of  bindings  definition  by  several  standards  organizations.  These  standards  and 
specifications  are  for  standards  bindings  to  the  FORTRAN  programming  language. 

3.2.4.3.1  Standards.  Table  3.2-30  presents  standards  for  FORTRAN  bindings. 


TABLE  3.2-30  FORTRAN  bindings  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

1FFF 

POSIX  FORTRAN  77  Language  Interface*  -  Part  1: 
Binding  for  Syitem  API 

1003.9:1992 

Informational 

(Approved) 

IPC 

ISO 

GKS-3D  FORTRAN  binding 

8806  1:1988 

Informational 

(Approved) 

IPC 

ISO 

Apoecdix  for  COBOL,  FORTRAN,  Pascal,  and  PL/1 
binding*  to  SQL2  (Technical  <ooteot  of  ISO  9075: 198$, 
SQL,  i*  retained  ai  a  leve',  of  the  1992  itandanl) 

9075:1992 

Appendix 

Informational 

(Approved) 

IPC 

ISO/IEC 

PH1GS  FORTRAN  binding 

9593-1:1990 

Informational 

(Approved) 

GPC 

NIST 

PKIGS  FORTRAN  binding  (Adopts  ISO/IEC 
9593.1:1990) 

FIPS  PUB 
153:1992 

Informational 

(Approved) 

GPC 

NIST 

FORTRAN  binding  to  GKS 

FIPS  PUB  120- 
1:1994 

Informational 

(Approved) 

NPC 

ANSI 

PHIGS  FORTRAN  binding  (X3.144.1) 

X3. 144.1 

Informational 

(ARMoved) 

NPC 

ANSI 

FORTRAN  binding  to  GKS 

X3.124.M985 

(R1991) 

Informational 

(Approved) 

NPC 

IEEE 

FORTRAN- 90  binding*  to  POSIX 

1003.19 

Informational 

(Draft) 

3.2.4.3.2  Standards  conformance.  Conformance  to  the  ISO/ANSI  1539-1990  standard  or  FIPS 
69-1  is  required. 

3.2.4.3.3  Alternative  specifications.  No  other  specifications  are  available. 

3.2.4.3.4  Standards  deficiencies.  Many  standards  lack  a  FORTRAN  binding,  even  in  draft  form. 

3.2.4.3.5  Portability  caveats.  Portability  problems  related  to  the  existing  bindings  are  unknown. 

3.2.4.3.6  Related  standards.  Other  related  standards  are  unknown. 

3.2.4.3.7  Recommendations.  No  standards  are  recommended  for  FORTRAN.  Work  on  IEEE 
1003.19  has  been  suspended.  FORTRAN  bindings  should  be  used  only  in  the  absence  of  an 
equivalent  Ada  binding.  A  layered  Ada  to  FORTRAN  binding  approach  should  be  taken  to  allow 
rapid  migration  to  the  Ada  binding  when  it  becomes  available. 
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3.2A.4  Bindings  to  COTS  products.  These  standards  and  specifications  are  for  bindings  for 
COTS  products  to  a  programming  language  (i.e.,  Ada). 

3.2.4.4.1  Standards.  Table  3.2-31  presents  standards  for  bindings  to  COTS  products. 


TABLE  3.2-31  Bindings  to  COTS  products  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

^^1 

CPC 

QSF 

OSF/Motif  binding  to  Ad* 

TBD- OSF/Motif 
binding  to  Ad* 

Information*! 

(Approved) 

IPC 

ISO/IEC 

SQL  Ad*  Module  Description  Language  (SAMeDL),  Rnt 
Edition 

12227:1995 

Information*! 

(Approved) 

TBD 

TBD 

Trans  million  Control  Protocol/Intemet  Protocol  (TCP/IP) 
Ad*  binding*  (binding  for  Ada-83) 

TBD-Tnuumiinon 

Control 

Piotocol/lntemet 
Protocol  (TCP/IP) 
Ad*  binding! 
(binding  for  Ad*- 

83) 

Informational 

(Formative) 

3.2.4.4.2  Alternative  specifications.  A  number  of  Ada  bindings  to  Microsoft  Windows.  These 
are  proprietary,  as  is  Microsoft  Windows,  and  should  be  used  only  to  support  legacy  products. 

3.2.4.4  .3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.4.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.2.4.4.6  Related  standards.  No  other  specifications  are  known. 

3.2.4.4.7  Recommendations.  No  standards  are  recommended  for  COTS  Ada  bindings. 
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3.2.5  Software  Engineering  Security  Services.  Security  engineering  activities  are  critical 
processes  during  the  software  development  life-cycle,  as  well  as  during  system  operation  and 
maintenance.  Concentration  on  the  analysis  and  allocation  of  security  requirements  is  the  major 
goal  to  be  accomplished.  Once  developed,  software  systems  must  take  into  account  operational 
concerns  such  as  cerdficadon  and  accreditation,  risk  management,  and  accountability  functions. 
For  users  of  the  ITSG  who  are  not  familiar  with  security  terminology,  study  of  the  following 
references  is  suggested: 

a.  National  Information  Systems  Security  (INFOSEC)  Glossary,  National  Security 
Telecommunications  and  Information  Systems  Security  (NTISSI)  No.  4009,  5 
June  1992. 

b.  Glossary  of  Telecommunications  Terms,  FED-STD-1037B,  3  June  1991. 

c.  Dictionary  of  Information  Systems,  ANSI  X3. 172,  1 990. 

d.  Security  in  Open  Systems  -  Data  Elements  and  Service  Definitions,  ECMA 
138:1989  (based  on  ECMA  TR46:1988). 

e.  Glossary  of  Computer  Security  Terms,  NCSC-TG-004,  version  1,  21  October 
1988. 

3.2.5.1  Security  models  and  architectures.  (This  BSA  appears  in  part  2  and  part  10.)  Security 
models  provide  the  necessary  basis  for  the  development  of  security-related  protocols  and  security- 
related  protocol  elements. 

3.2.5.1.1  Standards.  Table  3.2-32  presents  standards  for  security  models  and  architectures. 


TABLE  3.2-32  Security  models  and  architectures  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(same  as  CCITT  X.800:1991) 

7498.2:1989 

Informational 

(Approved) 

CPC 

CEN/CENELEC/ 

ITAEOV 

Taxonomy  of  Security  Standardization 

ITAEGV  N69  Ver 

2  of  4/30/1992 

Informational 

(Approved) 

IPC 

ECMA 

Security  in  Open  Systems  -  Data  Elements  and  Service 
Definitions 

138(1989) 

Informational 

(Approved) 

IPC 

ECMA 

Security  in  Open  Sy  items  -  A  Security  Frameworfc 

TR/46  ( 1988) 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Security  of  Computer  Applications 

FIPS  PUB  73:1980 

Informational 

(Approved) 

IPC 

ITU-T 

Security  Architecture  for  OSI  for  CCITT  Applications: 
Security.  Structure,  and  Applications 

X.800  (1991) 

Informational 

(Approved) 

CPC 

XADpen 

Security  Guide  (Second  Edition) 

G010(2/91) 

Infotmational  J 
(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ITU-T 

Reference  Model  of  OSE  for  CCITT  Applications-Data 
Communication*  Networks-GSI  Model  and  Notation, 
Service*  Definition 

X.200(1989) 

Informational 

(Approved) 

IPC 

ISO 

OSI  Brute  Reference  Model,  Part  3:  Naming  and 
Addressing 

7498-3:1989 

Informational 

(Approved) 

IPC 

ISO 

OSI  Baiic  Reference  Model,  Pvt  4:  Management 
Framework 

7498-4:1989 

Informational 

(Approved) 

IPC 

iso/mc 

9594-3:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory:  Procedure*  for  DistribUed 
Operation s: (tame  ai  ITU-T  X.519(1993)) 

9594-4:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

hhki 

9594-8:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO 

OSI  Upper  Layer  Security  Model 

10745:1993 

Informational 

(Approved) 

CPC 

X/Open 

Distributed  Security  Framework 

0410(12/94) 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Vernon  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

NPC 

rppp. 

Guide  to  the  POSIX  Open  Syitem#  Environment  •  A 
Security  Frame  wo  ik 

P1003.22:  1995 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Systems,  Part  I : 
Overview 

10181-1 

Informational 

(Draft) 

IPC 

ISO/IEC 

Guide  to  Open  Systems  Security 

TR  by 

JTC1/SC21/N8380 

Informational 

(Draft) 

IPC 

ISO/IEC 

Management  Plan  for  Security 

JTC1/SC21  SD-7 

Informational  1 
(Draft)  S 

3.2.5.1.2  Alternate  specifications.  There  are  no  alternate  specifications. 

3.2.5. 1.3  Standards  deficiencies.  FIPS  PUB  73  does  not  include  information  on  modern  security 
concepts. 

3.2.5.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.5.1.5  Related  standards.  There  are  no  related  standards. 

3.2.5.1.6  Recommendations.  The  DGSA,  Volume  6  of  the  TAFIM,  is  the  abstract  and  generic 
security  architecture  of  the  TAFIM.  The  DGSA  provides  security  principles  and  target  security 
capabilities  to  guide  system  security  architects  in  creating  specific  security  architectures  consistent 
with  the  DGSA.  The  DGSA  should  be  used  by  system  security  architects  to  develop  logical  and 
specific  security  architectures. 
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3X52  System  development  security.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 
Development  of  secure  systems  requires  that  security  engineering  be  a  key  discipline  in 
conjunction  with  other  system,  software,  and  hardware  engineering  activities. 

3. 2.5. 2.1  Standards.  Table  3.2-33  presents  standards  for  system  development  security. 


TABLE  3.2-33  System  development  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  Interpretation 

NCSC-TG-005, 
Version  1:  1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  System*  Evaluation  Criteria 

NCSC-TG-021, 
Version  1: 1991 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Service* 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

DOD 

FORTE2ZA  Cryptologic  Programmers'  Guide 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Application  Implementors'  Guide 

MD400210M.52: 

1996 

Mandated 

(Approved) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Informational 

(Approved) 

IPC 

ISO/IEC 

So.'' Ware  Life  Cycle  Processes 

12207:1995 

Informational 

(Approved) 


Trill  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  FYoceitei  -  Software  Development  - 
Acquirer-Supplier  Agreement 


EIA/IEEE  J-STD- 
016: 1995 


Informational 

(Approved) 


Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 


DCF.  Rev. 
1.2.2:1996 


OSI  Buie  Reference  Model,  Part  2:  Security  Architecture 
(same  uCCITTX.800: 1991) 


Informational 

(Approved) 


Guideline*  for  Security  of  Computer  Application* 


Informational 

(Approved) 


FIPS  PUB  83:1980 


Informational 

(Approved) 


OSI  The  Directory:  Abstract  Service  Definition:  (same  as 

ITU-T  X.5 1 1  (1993)) 


9594-3:1993  (or 

1994) 


Informational 

(Approved) 


ISO/EC 


OSI  The  Directory:  Procedures  for  Distributed 
Operations :( same  at  ITU-T  X.5 19(  1993)) 


9594-4:1993  (or 
1994) 


Informational 

(Approved) 


OS!  The  Directory:  Authentication  Framework  (same  as 

ITU-T  X.509  (1993)) 


9594-8:1993  (or 
1994) 


Infoimational 

(Approved) 


X/Open 


Generic  Security  Service  API  (GSS-APl)  Base 


("441  (12/95) 


Informational 

(Approved) 


POSIX,  Part  1:  System  API  -  Amendment  n:  Protection, 
Audit,  and  Control  Interfaces  (C  Language),  Draft  15 


Legacy 

(Dr^ft) 


POSIX  Part  2:  Shell  and  Utilities  -  Amendment  n: 
Protection  and  Control  Utilities,  Draft  15 


Emerging 

(Draft) 


Generic  Security  Service  -  Application  Program  Interface, 
Version  2 


RFC  2078:  199? 


Emerging 

(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

IETF 

Independent  Data  Unit  Protection  Generic  Security 
Application  Program  Interface  (1DUP-GSS-API) 

dnft-ierf-cat-Kfop- 

gia-06.txt,  26 

November  1996 

Emerging 

(Draft) 

NPC 

fKFF 

Standard  for  Information  Technology  -  Software  Life  Cyde 
Proceaaea 

lEEEdSIA 

12207US*date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cyde 
Proceaaea -Life  Cyde  Data 

IEEE/E1A 
12207.  lUS-dale 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cyde 
Proceaaea  -  Implementation  Connderationa 

IEEE/EIA 

12207.2US-date 

Informational 

(Draft) 

3 .2. 5.2.2  Alternative  specification.  There  are  no  alternative  specifications. 

32.5.23  Standard  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.5.2.4  Portability  caveats.  There  are  no  portability  caveats. 

3.2.5.2.5  Related  standards.  DOD  Directive  5200.28  "Security  Requirements  for  Automated 
Information  Systems  (AISs),"  provides  the  DOD-wide  program  for  AIS  security.  It  provides 
mandatory,  minimum  AIS  security  requirements  for  systems  processing  classified,  sensitive  but 
unclassified,  and  unclassified  information.  For  intelligence  systems,  Director,  Central  Intelligence 
Directive  (DCID)  1/16,  "Security  Policy  for  Uniform  Protection  of  Intelligence  Processed  in 
Automated  Information  Systems  and  Networks,"  and  "Security  Manual  for  Uniform  Protection  of 
Intelligence  Information  Processed  in  Automated  Information  Systems  and  Networks,"  should  be 
used  in  conjunction  with  DOD  5200.28-STD.  The  following  guidelines  also  are  for  use  with 
DOD  5200.28-STD: 


a.  NCSC-TG-006,  Version  1, 28  March  1988,  A  Guide  to  Understanding  Configuration 
Management  in  Trusted  Systems 

b.  NCSC-TG-007,  Version  1, 2  October  1988,  A  Guide  to  Understanding  Design 
Documentation  in  Trusted  Systems 

c.  NCSC-TG-008,  Version  1,  15  December  1988,  A  Guide  to  Understanding  Trusted 
Distribution  in  Trusted  Systems 

d.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in  Trusted 
Systems 

e.  NCSC-TG-023,  Version  1,  July  1993,  A  Guide  to  Understanding  Security  Testing  and 
Test  Documentation  in  Trusted  Systems 

3.2.S.2.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 
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Standard 

Type 


Sponsor 


Standard 


Standard 

Reference 


CPC 

IETF 

Independent  Data  Unit  Protection  Generic  Security 
Application  Program  Interfax  (IDUP-GSS-APT) 

■EEE3 . 

Emerging 

(Draft) 

NPC 

IEEE 

Standard  for  Information  Tedurology- Software  Life  Cyde  i 
Proceaaee 

EEE/E1A 

12207US-date 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  -  Software  Life  Cyde 

Proceaaee  •  Life  Cyde  Date  1 

ieee/eia 

12207.1  US-dale 

Informational 

(Draft) 

NPC 

IEEE 

Guide  for  Information  Technology  •  Software  Life  Cyde 
Proceaaee  -  Implementation  Cooawfcratiofti 

IEEE/EIA 

12207.2US-date 

Informational 

(Draft) 

3.2.5.2.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.2.5.2  J  Standard  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.5.2.4  Portability  caveats.  There  are  no  portability  caveats. 

3.2.5.2J  Related  standards.  DOD  Directive  5200.28  "Security  Requirements  for  Automated 
Information  Systems  (AISs),"  provides  the  DOD-wide  program  for  AIS  security.  It  provides 
mrndatory,  minimum  AIS  security  requirements  for  systems  processing  classified,  sensitive  but 
unclassified,  and  unclassified  information.  For  intelligence  systems,  Director,  Central  Intelligence 
Directive  (DCID)  1/16,  "Security  Policy  for  Uniform  Protection  of  Intelligence  Processed  in 
Automated  Information  Systems  and  Networks,"  and  "Security  Manual  for  Uniform  Protection  of 
Intelligence  Information  Processed  in  Automated  Information  Systems  and  Networks,"  should  be 
used  in  conjunction  with  DOD  5200.28-STD.  The  following  guidelines  also  are  for  use  with 
DOD  5200.28-STD: 

a.  NCSC-TG-006,  Version  1,  28  March  1988,  A  Guide  to  Understanding  Configuration 
Management  in  Trusted  Systems 

b.  NCSC-TG-007,  Version  1,  2  October  1988,  A  Guide  to  Understanding  Design 
Documentation  in  Trusted  Systems 

c.  NCSC-TG-008,  Version  1,  15  December  1 988,  A  Guide  to  Understanding  Trusted 
Distribution  in  Trusted  Systems 


d.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in  Trusted 
Systems 


e.  NCSC-TG-023,  Version  1,  July  1993,  A  Guide  to  Understanding  Security  Testing  and 
Test  Documentation  in  Trusted  Systems 


3.2.5.2.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 
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MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  MIL-STD-498  contains  requirements  for  security  and  privacy  for  software 
development  and  documentation.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640) 
is  based  on  MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use 
standard.  It  is  anticipated  that  J-STD-0 16  will  be  upgraded  from  trial  use  to  full  use  and  issued  as 
an  ANSI  standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of 
ISO/IEC  12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a 
base  standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207. 1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  approval,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

If  FORTEZZA  services  are  used,  the  following  two  guidelines  should  be  consulted: 

a.  MD4002101-1.52, 3/5/96,  FORTEZZA  Application  Implementors'  Guide 

b.  MD4000502- 1 .52,  1/30/96,  FORTEZZA  Cryptologic  Programmers'  Guide, 
Revision  1.52 
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3.2  J  J  Personal  authentication.  (This  BSA  appears  in  part  2,  part  3,  part  9,  and  part  10.) 
Personal  authentication  supports  the  accountability  objective  of  being  able  to  trace  all  security 
relevant  events  to  individual  users.  In  addition  to  supporting  unique  identification,  standards  are 
provided  to  authenticate  the  claimed  identity. 

3. 2.5. 3.1  Standards.  Table  3.2-34  presents  standards  for  personal  authentication. 


TABLE  3.2-34  Personal  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

Del) 

(Lifecycle) 

CPC 

OSF 

DCE  1.1  Security 
Service*:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Paw  word  Usage 

FIPS  PUB  l  *  «• 

1945 

Mandated 

(Approved) 

CPC 

OSF 

DittribUed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  on  Evaluation  of  Technique*  for  AiMomated 
Personal  Identification 

FIPS  PUB  48:1977 

Informational 

(Approved) 

[PC 

ISO/IEC 

Information  Technology  -  Open  System*  loteiconnectioo  - 
The  Directory:  AiMheottcadon  Framework  edition  2  (Same 
as  ITU-T  X.509: 1993) 

9594-8.2:1993 

informational 

(Approved) 

GPC 

NIST 

Gukkine  for  Use  of  Advanced  Authentication  Technology 
Alternatives 

FIPS  PUB 
190:1994 

informational 

(Approved) 

CPC 

IETF 

A  One-Time  Password  System 

RFC  1938:  1996 

Emerging 

(Draft) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CQ  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

CPC 

IETF 

The  Kerberos  Network  Authentication  Sc*vice  (V5) 

RFC  1510:1993 

Informational 

(Draft) 

5.2.5.3.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.2.5.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 


3.2.5.3.4  Portability  caveats.  OSF  DCE  Version  1.1's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 

3.2.5.3.5  Related  standards.  The  following  standards  are  related  to  personal  authentication 
standards  (particularly  TCSEC): 

a.  DOD  5200.28-STD,  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

b.  NCSC-TG-017,  Version  1,  "A  Guide  to  Understanding  Identification  and 
Authentication  in  Trusted  Systems 
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c.  CSC-STD-002-85,  "Password  Management  G’lideline" 

d.  NCSC-WA-002-85,  "Personal  Computer  Security  Considerations'' 

e.  ITU-T  X.509  (1993)  (same  as  ISO  9594-8),  The  Directory:  Authentication 
Framework 

32S.3.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.2 .5.4  Certification  and  accreditation.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 
Certification  and  accreditation  constitute  a  set  of  procedures  and  judgments  leading  to  a 
determination  of  the  suitability  of  the  system  to  operate  in  the  targeted  operational  environment 

Accreditation  is  the  official  management  authorization  to  operate  a  system.  The  accreditation 
normally  grants  approval  for  the  system  to  operate  (a)  in  a  particular  security  mode,  (b)  with  a 
prescribed  set  of  countermeasures  (administrative,  physical,  personnel,  communications  security, 
emissions,  and  computer  security  controls),  (c)  against  a  defined  threat  and  with  stated 
vulnerabilities  and  countermeasures,  (d)  within  a  given  operational  concept  and  environment,  (e) 
with  stated  interconnections  to  other  systems,  (f)  at  an  acceptable  level  of  risk  for  which  the 
accrediting  authority  has  formally  assumed  responsibility,  and  (g)  for  a  specified  period  of  time. 
The  Designated  Approving  Authority(s)  (DAA)  formally  accepts  security  responsibility  for  the 
operation  of  the  system  and  officially  declares  that  the  specified  system  will  adequately  protect 
against  compromise,  destruction,  or  unauthorized  modification  under  stated  parameters  of  the 
accreditation.  The  accreditation  decision  affixes  security  responsibility  with  the  DAA  and  shows 
that  due  care  has  been  taken  for  security  in  accordance  with  the  applicable  policies. 

An  accreditation  decision  is  in  effect  after  the  issuance  of  a  formal,  dated  statement  of 
accreditation  signed  by  the  DAA,  and  remains  in  effect  for  the  specified  period  of  time  (varies 
according  to  applicable  policies).  A  system  processing  classified  or  sensitive  unclassified 
information  should  be  accredited  prior  to  operation  or  testing  with  live  data  unless  a  written 
waiver  is  granted  by  the  DAA.  In  some  cases  (e.g.,  when  dealing  with  new  technology,  during  a 
transition  phase,  or  when  additional  time  is  needed  for  more  rigorous  testing),  the  DAA  may  grant 
an  interim  approval  to  operate  for  a  specified  period  of  time.  At  the  end  of  the  specified  time 
period,  the  DAA  must  make  the  final  accreditation  decision. 

Certification  is  conducted  in  support  of  the  accreditation  process.  It  is  the  comprehensive  analysis 
of  both  the  technical  and  nontechnical  security  features  and  other  safeguards  of  a  system  to 
establish  the  extent  to  which  a  particular  system  meets  the  security  requirements  for  its  mission 
and  operational  environment.  A  complete  system  certification  must  consider  factors  dealing  with 
the  system  in  its  unique  environment,  such  as  its  proposed  security  mode  of  operation,  specific 
users,  applications,  data  sensitivity,  system  configuration,  site/facility  location,  and 
interconnections  with  other  systems.  Certification  should  be  done  by  personnel  who  are 
technically  competent  to  assess  the  systems  ability  to  meet  the  security  requirements  according  to 
an  acceptable  methodology.  The  resulting  documentation  of  the  certification  activities  is  provided 
to  the  DAA  to  support  the  accreditation  decision.  Many  security  activities  support  certification, 
such  as  risk  analysis,  security  test  and  evaluation,  and  various  types  of  evaluations. 

Ideally,  certification  and  accreditation  procedures  encompass  the  entire  life  cycle  of  the  system. 
Ideally,  the  DAA  is  involved  from  the  inception  of  the  system  to  ensure  that  the  accreditation 
goals  are  clearly  defined.  A  successful  certification  effort  implies  that  system  security  attributes 
were  measured  and  tested  against  the  threats  of  the  intended  operational  scenarios.  Additionally, 
certification  and  accreditation  are  seen  as  continuing  and  dynamic  processes;  the  security  state  of 
the  system  needs  to  be  tracked  and  assessed  through  changes  to  the  system  and  its  operational 
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environment  Likewise,  the  management  decision  to  accept  the  changing  system  for  continued 
operation  is  an  ongoing  decision  process. 

Standards  for  certification  and  accreditation  services  provide  definitions  and  procedures  for  the 
testing  and  accreditation  of  computer  systems  in  so  far  as  their  conformance  with  security 
standards  is  concerned. 

3. 2.5.4. 1  Standards.  Table  3.2-30  presents  standards  for  certification  and  accreditation. 


TABLE  3.2-35  Certification  and  accreditation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  System  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guideline  for  Computer  Security  Certification  rod 
Accreditation 

FIPS  PUB 
102:1983 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CO  Venion  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

GPC 

DOD 

DOD  Information  Technology  Certification  and 
Accrediutioo  Process 

DITSCAP:  1996 

Informational 

(Draft) 

3 -2.S.4.2  Alternate  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.2.5.4J  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  102  does  not  include  services 
for  the  certification  and  accreditation  of  all  modem  security  concepts.  No  known  up-to-date 
standards  exist  for  certification  and  accreditation. 

Certification  and  accreditation  evaluation  criteria  that  address  current  information  technology, 
such  as  distributed  computing  and  networking,  are  needed.  As  new  criteria  such  as  the  Common 
Criteria  emerge,  revision  of  existing  certification  and  accreditation  guidelines  may  be  required. 

3.2.5.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.2.5.4.5  Related  standards.  NCSC-TG-029,  "Introduction  to  Certification  and  Accreditation," 
January  1994,  discusses  basic  concepts  related  to  certification  and  accreditation  and  is  the  first  of 
a  series  of  guidelines  in  the  "Rainbow  Series"  supporting  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC)  standard. 

3.2.5.4.6  Recommendations.  The  mandated  standard  is  recommended. 

Procurements  that  require  that  an  AIS  be  certified  and/or  accredited  must  reference  DOD 
Directive  5200.28  and  applicable  designated  approving  authority  guidance.  DOD  Directive 
5200.28,  "Security  Requirements  for  Automated  Information  Systems  (AISs),"  requires 
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certification  and  accreditation  of  AIS.  FIPS  PUB  102,  Guidelines  for  Computer  Security  and 
Accreditation  provides  Federal  guidelines  for  certification  and  accreditation.  Because  of  its  age, 
this  FIPS  PUB  does  not  include  services  for  the  certification  and  accreditation  of  all  modem 
security  concepts.  OOD  5200.28-STD  provides  criteria  to  assess  security  assurances  of  trusted 
systems  to  specific  classes.  DCID  1/16  provides  security  requirements  for  systems  processing 
intelligence  information. 

The  DISA  CISS  and  NSA  are  each  developing  documents  that  will  standardize  the  certification 
and  accreditation  process  within  DOD.  Each  document  is  in  draft  form;  final  documents  are 
expected  to  be  issued  in  1997.  The  NSA  document,  "Certification  and  Accreditation  Process 
Handbook  for  Certifiers,"  will  be  published  as  a  "Rainbow"  series  document  supporting  the 
TCSEC  standard.  This  NSA  handbook  focuses  on  certification  and  accreditation  of  standalone 
systems.  The  DISA  CISS  document,  "DOD  Information  Technology  Certification  and 
Accreditation  Process"  (DITSCAP),  will  be  published  as  a  DOD  publication.  The  DITSCAP 
focuses  on  certification  and  accreditation  in  conjunction  with  the  programmatic  aspects  of  the 
Dn. 
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32.SS  Security  risk  management.  (This  BSA  appears  in  part  2,  part  7,  part  9,  and  part  10.) 
Security  risk  management  supports  accreditation  through  a  risk  analysis  of  an  information  system 
and  its  operational  environment,  and  the  steps  taken  to  manage  the  risk  requirements. 

3. 2.5.5. 1  Standards.  Table  3.2-36  presents  standards  for  security  risk  management 


TABLE  3.2-36  Security  risk  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

|g|| 

GPC 

DOD 

The  DOD  Touted  Computer  Syitemi  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guideline  for  the  Aaalyrii  of  Local  Art*  Network  Security 

FIPS  PUB 
191:1994 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Automated  Data  Procewiag  Ride  Analyst 

FIPS  PUB  65:1979 

Informational 

(Approved) 

GPC 

NIST 

Guide  lit*.:  for  Automatic  Data  Proceaiing  Physical 
Security  and  Riik  Management 

FIPS  PUB  31:1974 

Informational 

(Approved) 

3.2.5 5.2  Alternate  specifications.  No  alternative  specifications  are  known. 

3.2.5.S 3  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  31  does  not  include  information 
of  all  modem  security  concepts. 

3.2.5.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.2.5.5.5  Related  standards.  The  following  standards  are  related  to  the  TCSEC  standard: 

a.  CSC-STD-003-85  25  June  1985,  Computer  Security  Requirements  -  Guidance  for 
Applying  the  Department  of  Defense  Trusted  Computer  Security  Evaluation 
Criteria  in  Specific  Environments 

b.  CSC-STD-004-85,  25  June  1985,  Technical  Rationale  Behind  CSC-STD-003-85: 
Computer  Security  Requirements  -  Guidance  for  Applying  the  Department  of 
Defense  Trusted  Computer  Security  Evaluation  Criteria  in  Specific  Environments 

3.2.5.5.6  Recommendations.  The  mandated  standard  is  recommended.  Office  of  Management 
and  Budget  (OMB)  Circular  A- 130,  "Management  of  Federal  Information  Resources, '  provides 
guidance  on  effective  security  risk  management  of  federal  information  systems.  NIST  Special 
Publication  800-12,  "An  Introduction  to  Computer  Security:  The  NIST  Handbook"  provides 
additional  guidance  on  risk  management  DOD  Directive  5200.28  requires  a  risk  analysis  of  an 
information  system  be  conducted  in  its  operational  environment  to  support  accreditation  of  the 
information  system.  System  implementors  should  perform  the  risk  analysis  in  accordance  wit! 
CSC-STD-003-85  and  CSC-STD-004-85  to  determine  the  appropriate  DOD-5200.28-STD  class. 
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3.2.5.6  Detection  and  notification.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Detection 
and  notification  objectives  ensure  that  a  secure  system  has  the  capability  to  recognize  that  it  is: 
under  attack;  may  potentially  enter  a  non-available  state;  has  been  compromised;  or  has  failed  in  a 
potentially  compromising  manner.  Guidance  in  this  area  focuses  on  reporting  detected  security 
critical  conditions  to  proper  authorities,  and  implementing  predetermined  corrective  actions. 

3.2.5.6.1  Standards.  Table  3.2-37  presents  standards  for  detection  and  notification. 


TABLE  3.2-37  Detection  and  notification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28. 
STD:  1985 

Mandated 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

3.2.S.6.2  Alternate  specifications.  No  alternate  specifications  are  known. 

There  are  no  alternative  specifications. 

3.2.5.6J  Standards  deficiencies.  No  standards  deficiencies  are  known. 

3.2.5.6.4  Portability  caveats.  No  portability  caveats  are  known. 

3.2.5.6.5  Related  standards.  NSA's  C-Technical  Report-001,  Computer  Viruses:  Prevention, 
Detection,  and  Treatment,  and  NIST  SP  800-5,  A  Guide  to  the  Selection  of  Anti-Virus  Tools  and 
Techniques,  provide  guidance  on  computer  viruses.  The  following  specifications  support  the 
TCSEC  standard: 

a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-015,  Version  1,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

c.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.2.5.6.6  Recommendations.  The  mandated  standard  is  recommended. 
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32.SJ  Security  recovery,  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Recovery  guidance 
defines  provisions  to  allow  system  personnel  or  processes  with  the  proper  authorizations  to  repair 
or  eliminate  the  cause  of  security  relevant  failures,  isolate  compromised  portions  of  the  system, 
and  revalidate  proper  operations  prior  to  returning  the  system  to  a  fully  operational  secure  state. 

3.2.5.7.1  Standards.  Table  3.2-38  presents  standards  for  security  recovery. 


TABLE  3.2-38  Security  recovery  standard’ 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Traded  Computer  Sy item*  Evaluation  Criteria 

DOD  5200.28. 
STD:  1985 

Mandated 

(Approved) 

IFC 

CCKB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venioo  1.0 

CC  Venioo  1.0: 
1996 

Emerging 

(Draft) 

3.2.5.7.2  Alternate  specifications.  No  alternative  specifications  are  known. 

There  are  no  alternative  specifications. 

3.2.S.7  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.2.5.7.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
3.2.5.75  Related  standards.  The  following  specifications  are  related  to  the  TCSEC  standard: 

a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-022,  Version  1,  December  1991,  A  Guide  to  Understanding  Trusted 
Recovery  in  Trusted  Systems 

c.  NCSC-TG-015,  Version  1,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

d.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.2.5.7.6  Recommendations.  The  mandated  standard  is  recommended. 
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3-3  User  interface  services.  User  interface  services  define  how  users  may  interact  with  an 
application.  Depending  on  the  capabilities  required  by  users  and  the  applications,  these  interfaces 
may  include  window  management,  dialog  support,  and  user  interface  security. 

NOTE:  throughout  Part  3,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  IPC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3  .3.1  Introduction.  The  user  interface  is  a  combination  of  menus,  screen  design,  keyboard 
commands,  command  language,  and  help  screens,  which  create  the  way  a  user  interacts  with  a 
computer.  The  use  of  mice,  touch  screens,  and  other  input  hardware  are  included  as  part  of  the 
user  interface.  A  well-designed  user  interface  is  vital  to  the  success  of  an  application. 

A  graphical  user  interface  (GUI)  lets  users  initiate,  enter,  and  exit  applications  and  manipulate  the 
commands  in  those  applications  primarily  by  the  use  of  a  pointing  device  (often  a  mouse).  A  GUI 
uses  a  visual  metaphor  (icons)  representing  actual  desktop  objects.  The  user  can  access  and 
manipulate  these  icons  with  a  pointing  device  on  the  display. 

User  Interface  Services  (U1S)  provide  a  consistent  way  for  the  people  who  develop,  administer, 
and  use  a  system  to  gain  access  to  applications  programs,  operating  systems,  and  various  system 
utilities.  UIS  standards  define  the  multi-tier  environment  which  exists  between  applications  and 
the  operating  system  and  hardware  of  the  computer  platform. 

Historically,  software  applications  interfaced  directly  to  the  operating  system  and  even  to  the 
platform  hardware.  The  advent  of  the  GUI  and  the  desire  for  easy  to  use,  platform-independent, 
uniform  interfaces  for  user  applications  have  led  to  a  layered  approach  to  interfacing  well 
behaved,  user  friendly  applications  to  operating  systems  and  platforms.  Modem  GUI  based 
applications  predominately  interface  through  a  high  level  Windowing  Application  Programming 
Interface  (API)  which  provides  a  common  look  and  feel  to  users  across  applications  via  a  supplied 
toolkit  of  functions  and  data  structures.  This  interface  is  explicitly  designed  to  be  platform 
independent.  The  Windowing  API  interfaces  to  a  Basic  Windowing  Toolkit  which  provides 
middle  level  windowing  functionality.  At  this  level,  the  emphasis  is  also  on  platform 
independence,  but  look  and  feel  is  not  as  tightly  controlled  as  at  the  higher  level.  This  basic  toolkit 
interfaces  to  a  set  of  toolkit  primitives  which  supplies  an  operating  system  and  platform  specific 
interface.  Thus,  it  should  be  possible  to  write  cross-platform  applications  using  Windowing  API 
calls  and  require  implementation  of  platform  and  operating  system  specific  tailoring  at  the 
primitives  level.  These  three  intervening  layers  between  the  platform  and  the  operating  system  are 
the  areas  of  concern  for  UIS. 
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The  Adopted  Information  Technology  Standards  (AITS)  and  ITSG  recognize  Institute  of 
Electrical  and  Electronics  Engineers  (IEEE)  POSIX  operating  systems  and  hardware  as  the  open 
system  of  choice  for  the  Department  of  Defense  (DOD).  Graphical  user  interface  oriented 
applications  and  environments  are  emphasized  over  character-based  interfaces.  This  emphasis 
arises  from  the  realization  that,  for  modem  computer  systems,  GUIs  can  provide  consistent,  easy- 
to-use  software  to  users  and  thereby  lower  training  time  and  expense  and  enhance  individual 
productivity.  An  information  system  architecture  must  address  not  only  the  technical  features  of 
the  user  interface  but  also  the  human  engineering  considerations.  Thus,  many  of  the  U1S  standards 
discussed  in  this  part  of  the  ITSG  address  the  specification  of  aspects  of  a  GUI  environment 
layering  on  a  POSIX  operating  system. 

The  major  UIS  standards  issues  facing  DOD  is  the  widespread  use  within  DOD  of  Microsoft 
Windows  (MS  Windows)  GUI  platforms.  This  usage  mirrors  the  85%  commercial  market 
dominance  of  MS  Windows.  While  POSIX  systems  are  the  adopted  DOD  standard,  the  vast 
majority  of  DOD  systems  are  based  upon  MS  Windows.  Commercial  users  may  accept  the 
proprietary  MS  Windows  as  a  de  facto  standard,  but  <K  OOP*  OSE  mandate  does  not  allow  the 
adoption  of  this  single  vendor  product  as  a  standard' t-<  •  total  reliance  of  the  US 
defense  establishment  on  the  caprice  of  a  single  co>  .v  :  5cv.ii.  y.  :.rn; .»  v,..>  due  to  economic  and 
office  automation  compatibility  reasons,  these  platforms  are  commonly  pt  .  .-  d  :rr  DOD 
agencies  and  services  in  circumvention  of  the  OSE  standards. 

A  solution  to  this  issue  is  being  sought  in  the  current  consortium  development  activity  by  a 
working  group  within  the  European  Computer  Manufacturer's  Association  (ECMA)  to  produce 
an  ISO  standard  for  an  Applications  Programming  Interface  for  Windows  (APIW).  The  APIW 
will  be  an  open  specification  based  upon  key  MS  Windows  3.1  functionality.  This  ECMA/1SO 
standard  will  allow  eventual  adoption  of  the  APIW  by  DOD  as  a  GUI  windowing  API,  thus 
legitimizing  existing  Windows  platforms  and  encouraging  other  vendors  to  develop  alternate, 
compliant  UIS  windowing  products. 

There  are  several  standards  defining  organizations  which  are  significant  contributors  to  UIS  IT 
standards.  To  aid  the  reader  in  following  the  standards  discussions  in  this  chapter,  these 
organizations  are  briefing  described  in  the  following  paragraphs. 

The  National  Institute  of  Standards  and  Technology  (NIST),  part  of  the  Department  of 
Commerce,  is  the  primary  standards  defining  agency  for  the  US  government.  NIST,  formerly  the 
National  Bureau  of  Standards,  produces  the  Applications  Portability  Profile  (APP)  and  Federal 
Information  Processing  Standard  (FIPS).  NIST  Standards  in  this  chapter  are  labeled  as  GPC. 

The  Institute  of  Electrical  and  Electronic  Engineers  (IEEE)  is  an  open,  non-profit  standards 
making  body  composed  of  over  10, COO  engineers,  scientists,  and  students  in  electronics  and 
related  fields.  IEEE  produces  telecommunications  and  computing  standards  include  those  for  and 
relating  to  the  POSIX  operating  system.  Adopted  IEEE  standards  for  UIS  are  noted  as  NPC. 

The  Open  Software  Foundation  (OSF)  is  a  non-profit  organization  which  emphasizes  the 
development  of  open  computing  environment  standard  products.  Motif  and  the  Distributed 
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Computing  Environment  (DCE)  are  their  primary  UIS  standard  specifications.  ITSG  adopted 
OSF  standards  are  CPC. 

X/OPEN  is  a  consortium  of  computer  manufacturers  which  promotes  the  development  of 
information  technology  specific  os  based  on  UNIX  and  provides  a  program  for  product 
branding.  X/OPEN  standards  are  denoted  as  CPC. 

The  Common  Open  Software  Environment  (COSE)  was  a  consortium  of  six  UNIX  vendors. 
COSF  !n  now  defunct  and  its  primary  standard  specification,  the  Common  Desktop  Environment 
(CDE)  is  now  being  developed  by  X/OPEN. 

The  Organization  for  International  Standards  (ISO)  sets  a  broad  range  of  international  standards. 
For  information  technology,  ISO  has  established  the  Joint  Technical  Committee  for  Information 
Technology  (JTC1).  ISO  UIS  standards  are  labeled  as  IPC. 

Several  standards,  particularly  those  which  relate  to  GUIs,  are  referenced  by  a  number  of  base 
service  areas  discussed  Li  the  following  sections.  Additionally,  while  each  set  of  standards 
associated  with  a  base  service  area  are  summarized  in  a  table  in  each  section,  there  is  significant 
overlap  between  these  common  standards.  A  summary  of  these  key  standards,  the  various  base 
service  areas  addressed  by  each,  and  the  overlap  of  the  standards  is  presented  in  the  following 
discussion. 

FIPS  158-1,  The  User  Interface  Component  of  the  Applications  Portability  Profile,  October  8, 
1993,  adapts  the  X  Protocol,  Xlib  Interface,  Xt  Intrinsics,  and  Bitimp  Distribution  Format  (BDF) 
specifications  of  the  X  Window  System,  Version  1 1,  Release  5  (XI 1R5).  (See  following 
paragraph.)  This  current  version  supersedes  the  original  FIPS  158,  X-Windows  User  Intc.face, 
May  1990,  which  was  based  upon  X  Windows  System,  Version  1 1,  Release  3  (XI 1R3)  and 
compatible  with  XI 1R4.  (The  name  of  the  older  standard  differs  from  the  current  standard  as  it 
predated  the  existence  of  the  NIST  APP.)  A  new  version,  FIPS  158-2,  is  being  developed  to 
adopt  the  new  XI 1R6  windowing  standard.  Whenever  FIPS  158-1  is  referenced  in  a  base  service 
area,  it  is  the  adopted  standard  in  the  AITS.  Components  of  this  standard  are  referenced  in  the 
following  base  service  areas  (BSAs): 

3.3.3. 1  Data  stream  encoding 

3.3.3.2  Data  stream  interface 

3. 3.3.3  Subroutine  foundation  library 

3.3.3.4  Raster  data  interchange 

3. 3. 3.6  User  Interface  Management  System 

3. 3.3.7  Data  interchange  format  for  GUI-based  applications 

3. 3.4.4  Three-dimensional  appearance 

The  original  FIPS  158  is  noted  in  these  base  service  areas  as  a  superseded  standard  which 
supports  legacy  systems  based  upon  XI 1R3  and  XI 1R4.  FIPS  158-2  is  noted  as  a  formative 
standard  in  the  base  service  area  called  Communications  between  GUI  client  applications. 


April  7,  1997 


3.3-3 


Version  3. 1 


Information  Technology  Standards  C.uidana 


User  Interface  Services 


XI 1R6  is  the  current  release  (May  1994)  of  the  X-Windows  standard  developed  by  the  MIT  X 
Consortium.  It  is  a  GUI  standard  which  provides  portability  of  information  across  hardware  and 
operating  systems  and  allows  applications  and  resources  to  be  distributed  across  a  network,  based 
upon  a  client-server  architecture.  XI 1R6  implements  advanced  windowing  concepts  and  support 
"thread  safe"  multi-threading.  As  no  significant  products  are  as  yet  available  for  the  newly 
released  XI 1R6,  the  previous  version,  XI  IRS,  as  adopted  by  FIPS  1SS-1,  remains  as  the 
accepted  secondary  reference  standard  for  many  UIS  BSAs,  including  all  BSAs  noted  above, 
except  Raster  data  interchange  and  User  Interface  Management  System.  Additionally,  XI  IRS  and 
XI 1R6  are  referenced  independently  in  the  following  base  service  areas: 

3.3.4.6  Customization  to  local  norms 

3.3.5. 1  Independent  window  management  services 

XI 1R6  is  listed  as  the  primary  standard  in  base  service  area  called  A  windows  over  Open  Systems 
Interconnection  (OSI)  at  3.3.3. 1 1.  XI  IRS  does  not  address  this  BSA. 

OSF/Motif  Version  2.0  is  the  current  version  (June  1994)  of  the  Open  Systems  Foundation 
specification  for  GUI  behavior  and  screen  appearance  for  applications  running  on  systems  that 
support  XI  IRS.  It  includes  an  API  consisting  of  a  toolkit  (adopted  by  IEEE  MTE,  1295),  a  User 
Interface  Language,  the  Application  Environment  Specification  (AES),  and  a  style  guide.  It  is 


somewhat  incompatible  with  the  multi-threading  implementation  in  the  new  XI 1R6  standard.  As 
no  significant  products  are  as  yet  available  for  the  newly  released  Motif  2.0,  the  previous  version 
Motif  1.2  remains  as  the  reference  standard  for  many  UIS  BSAs.  Adoption  of  Motif  2.0  as  an 
ITSG  standard  will  be  delayed  until  an  appropriate  threshold  of  Motif  2.0  products  is  available 
and  until  potential  conflicts  between  Motif  2.0  and  XI 1R6  are  resolved.  Components  of  the 
Consortia  Public  Consensus  Motif  2.0  and  1.2  standards  are  referenced  in  the  following  base 

service  areas: 

3.3.3. 1 

Data  stream  encoding 

3.3.J.2 

Data  stream  interface 

3. 3.3.3 

Subroutine  foundation  library 

3. 3.3.6 

User  Interface  Management  System 

3. 3.3.7 

Data  interchange  format  for  GUI-based  applications 

33.3.8 

X  Logical  Font  Description 

3. 3. 3.9 

Compound  text  encoding 

3.3.4. 1 

Application  programming  interfaces 

3.3.4.2 

User  Interface  Definition  Language 

3.3.4.3 

GUI  style  guides 

3.3.4.5 

Interchange  format  for  design  tools 

3. 3.4.6 

Customization  to  local  norms 

3.3.4.7 

Language  bindings  for  GUIs 

3.3.5. 1 

Independent  window  management  services 

3.3. 5. 2 

Multiple  displays 

3. 3. 5.4 

On-line  help 

3.3.S.5 

Drivability 
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3.3.S.6  Commands,  menus,  and  dialog  services 

The  IEEE  Modular  Toolkit  Environment  (IEEE  MTE,  1295)  is  a  standard  for  GUI  applications 
and  user  interfaces  to  open  systems  and  defines  the  application  interface  to  display  objects 
(widgets)  built  upon  the  X  Window  System  X  Toolkit  Intrinsics.  It  adopts  the  software  interface 
toolkit  associated  with  OSF/Motif  Version  1.2.  As  with  Motif,  the  MTE  defines  a  C  language 
binding.  It  is  referenced  as  an  approved  standard  in  base  service  areas  Application  programming 
interfaces,  3.3.4. 1,  and  Language  bindings  for  GUIs,  3.3.4.7. 

The  Human-Computer  Interface  (HCI)  Style  Guide,  Version  3.0,  is  a  DOD  publication  that 
provides  a  common  framework  for  HCI  design  and  implementation  with  particular  emphasis  on 
standard  look  and  feel  for  GUI  based  applications.  It  is  currently  published  as  volume  8  of  the 
Technical  Architecture  Framework  for  Information  Management  (TAFIM).  This  DOD  style  guide 
is  adopted  as  the  AITS  standard  in  the  following  base  service  areas: 

3.3.2.2  Human  factors  for  video  display  terminals 

3.3.2.3  Human  factors  for  keyboards 

3.3.2.4  Human  factors  for  non-keyboard  input  devices 

3.3.2.5  Human  factors  for  the  physical  environment 

3.3.4.3  GUI  style  guides 

3.3.4.6  Customization  to  local  norms 

3.3.4.9  Color  use 

3.3.5.4  On-line  help 

3. 3.5. 5  Drivability 

3.3.5.6  Commands,  menus,  and  dialog  services 

3.3.8. 1  User  interface  security  labeling 

UIS  standards  must  be  consistent  with  other  ITSG  service  areas.  It  has  already  been  noted  that 
UIS  standards  are  consistent  with  the  DOD  mandate  of  the  POSIX  operating  system  standard. 
Three  other  base  service  areas  discussed  in  this  part  of  ITSG  have  a  direct  overlap  with  other 
service  areas.  These  areas  and  the  overlapping  service  areas  are  listed  below: 

3.3.8  Security  base  service  areas,  cloned  from  the  equivalent  base  service  areas  in 
Security  Services. 

3.3.3.4  Raster  data  interchange,  cloned  from  the  BSA  in  Data  Interchange  Services 
and  coincident  with  the  BSA  in  Graphics  Services. 

3. 3.6.3  Electronic  forms,  cloned  from  the  BSA  in  Data  Management  Services  and 

coincident  with  the  BSA  in  Data  Interchange  Services. 

Modern  systems  and  applications  are  and  will  be  based  upon  graphical  user  interfaces  and  the 
associated  standards  for  such  systems.  However,  many  legacy  systems  still  include  a  large  number 
of  character-based  terminals.  Base  service  areas  for  character-based  display  terminals  discuss 
standards  which  can  be  applied  to  such  systems.  No  recommendations  are  made  as  to  the  use  of 
these  standards  on  legacy  systems,  since  such  recommendations  may  be  inappropriately  or 


April  7,  1997 


3.3-5 


Version  3. 1 


Information  Technology  Standards  Guidance 


User  Interface  Services 


uneconomically  applied  to  such  systems.  Should  a  new  system  be  developed  employing  such 
technology,  the  appropriate  character-based  standards  should  be  used. 
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332  User  interface  hardware.  User  interface  hardware  deals  with  all  forms  of  hardware  used 
to  provide  an  interface  between  humans  and  computers.  These  devices  include,  for  example, 
keyboards. 

3J.2.1  Keyboard  device  layout.  (This  BSA  appears  in  both  part  3,  User  Interface,  and  part  14, 
Internationalization.)  Keyboard  device  layout  standards  specify  the  arrangement  of  keys  on  a 
keyboard. 

3.3.2.1.1  Standards.  Table  3.3-1  presents  standards  for  keyboard  device  layout. 


TABLE  3.3-1  Keyboard  device  layout  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Keyboard  Layouts  for  Text  and  Office  Systems 

9995*1, .8: 1994 

Mandated 

(Approved) 

GPC 

DOD 

Military  Standard  Keyboard  Arrangements 

M1L*STD*1280, 
Notice  1, 1969 

Informational 

(Approved) 

NPC 

ANSI 

Allocation  of  Letters  to  the  Keys  of  Numeric  Keypads 

T1.703  (1995) 

Informational 

(Approved) 

NPC 

ANSI 

Coded  Character  Sets  for  Keyboard  Arrangement  in  ANSI 
X4.23- 1982  and  X4.22- 1983 

X3.1 14-1984 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Keyboard  Arrangement 

X3.154- 1988 

Informational 

(Approved) 

NPC 

ANSI 

Alternate  Keyboard  Arrangement 

X3, 207-1991 

Informational 

(Approved) 

CPC 

X/Open 

Key  Values  (in  Window  Management,  Issue  3) 

XPG3  Vol.6C216 

Informational 

(Approved) 

IPC 

ISO 

Keyboard  Layouts  for  Numeric  Application* 

3791s 1976 

Informational 

(Approved) 

IPC 

ISO/IEC 

Numeric  Keyboard  for  Home  Electronic  Systems  (HES) 

946:1988 

Informational 

(Approved) 

IPC 

ECMA 

Common  Secondary  Keyboard  Layout  for  I  anguages 
Using  a  Latin  Alphabet 

115(1986) 

Informational 

(Canceled) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 
Display  Terminals  (VDTs)  part  4:  Keyboard  requirements 

9241-4 

Informational 

(Draft) 

IPC 

ISO 

Keyboard  for  International  Information  Processing 
Interchange  Using  the  ISO  7-Bit  Coded  Character  Set  • 
Alphanumeric  Area 

2530:1975 

Informational 
(Superseded)  Q 

IPC 

ISO 

Keyboard  Layouts  for  Text/Office  Systems 

3243:1975 

Informational  | 
(Superseded)  U 

IPC 

ISO 

Keyboard  Layouts  for  Text/Office  Systems 

3244:1984 

Informational  E 
(Superseded)  | 

IPC 

ISO 

Keyboard  Layouts  for  Text/Office  Systems 

8884:1987 

Informational 

(Superseded) 

NPC 

ANSI 

Keyboard  Arrangement 

X4.23-1982 

Informational 

(Superseded) 

■WWW’ 
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3-3.2. 1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3 -3.2. 1J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

33.2.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

33.2.1.5  Related  standards.  No  standards  are  related  to  keyboard  device  layout  standards. 

33.2.1.6  Recommendations.  Conformance  to  all  ISO  and  ISO/IEC  keyboard  specifications 
conforming  to  DIS  or  IS  levels  is  recommended.  This  is  especially  important  for  equipment  that 
will  interoperate  with  that  of  U.S.  allies  (e.g. ,  NATO). 
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33.2.2  Human  factors  for  video  display  terminals.  (This  BSA  appears  in  both  part  3,  User 
Interface,  and  part  13,  Human  Factors.)  This  base  service  area  addresses  the  human  factors 
requirements  for  all  types  of  video  displays,  and  includes  safety  concerns. 

3.33.2.1  Standards.  Table  3.3-2  presents  human  factors  standards  for  video  display  terminals. 


TABLE  3.3-2  Human  factors  for  video  display  terminals  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Homan -Compute,-  Interface  (HCI)  Style  Guide 

TAF1M  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 
Display  Terminals  (VDTs)  Part  1 :  Introduction 

9241-1:1992 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 
Display  Teiminals  (VDTs)  Part  2:  Task  Requirements 

9241-2: 1992 

Informational 

(Approved) 

IPC 

ISO 

9241-3:1992 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

MIL-STD-1472D 
Notice  2, 30  June 
1992 

Informational 

(Approved) 

IPC 

ECMA 

136(1989) 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principles  in  the  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 

NPC 

ANSI/AIIM 

Electronic  Imaging  Output  Displays 

TR19-1993 

Informational 

(Approved) 

CPC 

NSC 

Guide  to  Working  Safely  with  Computers  •  Manual  (relates 
to  VDTs) 

13068-0000 

Informational 

(Approved) 

IPC 

ECMA 

Procedure  for  Measurement  of  Emissions  of  Electric  and 
Magnetic  Fields  from  VDUs  from  5  Hz  to  400  kHz' 

172  (1992) 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Wort  with  VDTs  Part 

8:  Requirements  for  displayed  colors 

9241-8 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 
7:  Display  requirements  with  reflections 

9241-7 

Informational 

(Draft) 

IPC 

ISO 

Flat  Panel  Display  Ergonomic  Requirements 

13406 

Informational 

(Draft) 

NPC 

ANSI/HFS 

Human  Factors  Engineering  of  Visual  Display  Terminal 
Workstations  (Rev.  1) 

100-1988  (Revision 
1) 

Informational 
(Draft  (WD)) 

!PC 

ECMA 

Ergonomics  -  Requirements  for  Colour  Visual  Display 
Devices 

126  (1987) 

Informational 

(Canceled) 

IPC 

ECMA 

Ergonomics  -  Requirements  for  Monochromatic  Visual 
Display  Devices 

110(1985) 

Informational 

(Canceled) 

3.33.2.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 
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33.2.23  Standards  deficiencies.  The  performance-based  test  described  in  ISO  9241-3 
adequately  discriminates  between  a  display  that  meets  the  physical  requirements  of  the  standard 
and  one  that  does  not  However,  timing  scores  may  be  badly  affected  by  the  effects  of  testing 
practice.  Changes  to  the  test  method  and  metrics  are  under  consideration.  ISO  9241-3  does  not 
adequately  address  flat  panel  displays.  ISO  13406  is  intended  to  remedy  this  situation. 

33.2.2.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 

33.2.23  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
video  display  terminals: 

a.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load.  Part  2: 

Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

b.  MIL-STD- 1 908  ( 1 992)  Definition  of  Human  Factors  Terms. 

c.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

d.  MIL-STD- 1 800A  ( 1 990)  Human  Engineering  Performance  Requirements  for 
Systems  (Air  Force  published,  but  rarely  used,  duplicates  MIL-STD- 1472). 

e.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

f.  MIL-HDBK-761A(1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

g.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

h.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

i.  ITU-T  E.  1 34  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

j.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.3.2.2.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  computer  displays.  Display 
characteristics  include  brightness  and  contrast,  character  legibility,  image  stability,  glare,  and  the 
use  of  color. 
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Note,  however,  that  ISO  human  factors/ergonomics  standards  are  either  normative  or  informative. 
An  informative  standard  contains  no  mandatory  requirements.  A  normative  standard  contains  one 
or  more  requirements  that  must  be  met  in  order  to  achieve  conformance  with  the  standard. 

ISO  9241-1  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO  9241  standard.  A 
revised  version  of  ISO  9241-1  is  currently  at  the  Committee  Draft  (CD)  level  and  will  soon  be 
released  for  Draft  International  Standard  (DIS)  ballot.  ISO  9241-2  presents  an  overview  of 
factors  that  should  be  considered  when  designing  tasks  to  be  performed  in  a  specific  computing 
environment 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative.  Part  3  of  the  ISO  9241  standard  is 
normative;  parts  2-9  are  expected  to  be  normative  on  completion.  Conformance  requirements  for 
each  normative  part  are  embedded  within  that  part  Conformance  with  the  overall  ISO  9241 
standard  is  based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  ISO  and  ISO/IEC  standards  cited  in  the  gray  area  of  the  table  are  being  balloted  and  revised 
at  a  rapid  rate.  Interested  parties  should  monitor  the  progress  of  these  standards  at  six  month 
intervals  to  ensure  they  have  the  latest  information.  Offerers  of  products  meeting  existing  or 
emerging  standards  should  be  required  to  provide  a  migration  plan  to  ensure  compliance  of  the 
products  with  the  final  standards  documents. 

The  DOD  HCI  Style  Guide  is  recommended,  in  particular  section  3,  which  deals  with  hardware. 
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33.2.3  Human  factors  for  keyboards.  (This  BSA  appears  in  both  part  3,  User  Interface,  and 
part  13,  Human  Factors.)  This  BSA  covers  keyboard  layout,  including  specific  directions  for 
layout  of  regions  of  the  keyboard,  and  keyboard  design.  Ease  of  use  and  correct  ergonomic  design 
also  are  a  part  of  this  BSA. 

3.33.3.1  Standards.  Table  3.3-3  presents  human  factors  standards  for  keyboards. 


TABLE  3.3-3  Human  factors  for  keyboards  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pnn 

GPC 

DOD 

Human-Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Put  1: 
General  principles  governing  keyboard  layout 

9995-1:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  2: 
Alphanumeric  section 

9995-2:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  3: 
Common  secondary  layout  of  the  alphanumeric  section 

9995-3:1994 

Informational 

(Approved) 

IPC 

ISO/EC 

Keyboard  Layout  fo;  Text  and  Office  Systems  Part  4: 
Numeric  section 

9995-4:1994 

Infoimationai 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  5: 
Editing  section 

9995-5:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  6: 
Function  section 

9995-6:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  7 : 
Symbols  used  to  represent  functions 

9995-7:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  8: 
Allocation  of  Letters  to  the  Keys  of  a  Numeric  Keyboard 

9995-8:1994 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

NPC 

ANSI 

Coded  Character  Sets  for  Keyboard  Arrangement  in  ANSI 
X4.23-1982  and  X4.22-1983 

X3.1 14-1984 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Keyboard  Arrangement 

X3. 154- 1988 

Informational 

(Approved) 

NPC 

ANSI 

Alternate  Keyboard  Arrangement 

X3.207-1991 

Informational 

(Approved) 

GPC 

DOD 

Militaiy  Standard  Keyboard  Arrangements 

MIL-STD-1280, 
Notice  1.  1969 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

MIL-STD-I472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

IPC 

IEC 

Man-Machine  Interface  (MMI)  -  Actuating  Principles 

447:1993 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma  Disorders:  a  Manual  for 
Musculoskeletal  Diseases  of  the  Upper  Limbs 

12221-0000 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principles  in  the  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecvde) 

NPC 

ACCIH 

Ergonomic  Intervention*  to  Prevent  Muiculoikektal 

In jurice  in  Industry 

9000:1987 

In/onaational 

(Ajpcoved) 

CPC 

NSC 

Evaluating  Your  Workplace:  Hand*  &  Ami  •  Ergonomic 
Change#  Manual 

12587-0004 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirement*  for  Office  Work  with  Viatal 
DiipUy  Tenainab  (VDTi)  pert  4:  Keyboard  requirement* 

9241-4 

Informational 

(Drift) 

NPC 

ANSl/HFS 

Human  Ffc~or»  Engineering  of  VituaJ  DiipUy  Terminal 
Workstations  (Rev.  1) 

100-1988  (Reviaion 
1) 

Informational 
(Draft  (WD)) 

2X2X1  Alternative  specifications.  There  are  no  alternative  specifications  available. 

33.2.33  Standards  deficiencies.  MIL-STD-1472D  is  in  need  of  a  comprehensive  revision  to 
update  technical  material  so  that  it  is  reasonably  consistent  with  the  state  of  the  art  and  to  ensure 
that  the  two  commands  not  currently  using  the  standard  can  do  so. 

3  .3, 2.3.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 

33.2.33  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
keyboards: 

a.  ISO  9241-1:1992,  Ergonomic  requirements  for  office  work  with  visual  display 
terminals  (VDTs),  part  1:  Introduction,  presents  an  overview  of  the  content  and 
usage  of  the  multipart  ISO  9241  standard.  A  revised  version  of  ISO  9241-1  is 
currently  at  the  CD  level  and  will  soon  be  released  for  DIS  ballot 

b.  ISO  9241-2:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  presents  an  overview  of  factors  that  should  be  considered 
when  designing  tasks  to  be  performed  in  a  specific  computing  environment. 

c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  -  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  genera!,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

d.  MIL-STD- 1 908  ( 1 992),  Definition  of  Human  Factors  Terms. 

e.  MIL-STD- 1794  ( 1 986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

f.  MIL-STD- 1 800A  ( 1 990)  Human  Engineering  Performance  Requirements  for 
Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel,  (Draft  759C  is  complete.) 
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h.  M1L-HDBK-761  A(1989)  Human  Engineering  Guidelines  for  Management 

Information  Systems. 

L  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

j.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

k.  ITU-T  E.  134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

l.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.3.2.3.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  keyboards.  Keyboard 
characteristics  include  keyboard  height  slope,  profile,  surface  properties,  adjustability,  bounce 
and  character  repeat,  key  positioning,  key  displacement  and  force,  keytop  shape,  and  keytop 
legends. 

Parts  1  and  2  of  the  ISO  9241  standard  (see  related  standards)  are  informative.  Parts  2-9  are 
expected  to  be  normative  on  completion.  Conformance  requirements  for  each  normative  part  are 
embedded  within  that  part  Conformance  with  the  overall  ISO  9241  standard  is  based  on 
conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

Parts  1-8  of  the  ISO/IEC  9995  standard  are  normative.  Conformance  requirements  for  each 
normative  part  are  embedded  within  that  part.  Conformance  with  the  overall  ISO  9995  standard  is 
based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

The  DOD  HCI  Style  Guide  is  recommended,  particularly  for  section  3,  which  covers  hardware. 
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33.2.4  Human  factors  for  non-keyboard  input  devices.  (This  BSA  appears  in  both  part  3, 
User  Interface,  and  part  13,  Human  Factors.)  This  section  presents  human  factors  standards  for 
input  devices  other  than  keyboards.  These  devices  include  trackballs,  pens,  and  tablets  among 
others. 

3.33.4.1  Standards.  Table  3.3-4  presents  human  factors  standards  for  non-keyboard  input 
devices. 


TABLE  33-4  Human  factors  for  non-key  board  input  devices  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Syitemi  Part  7: 
Symbol*  uted  to  rtpreaent  function* 

9995-7:1994 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factor* 
Engineering  of  Viiual  Display  Terminal  Workstation* 

100-1988 

Informational 

(Approved) 

IPC 

EC 

Man- Machine  Interface  (MMI)  -  Actuating  Principle* 

447:1993 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principle*  in  (he  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma  Disorders:  a  Manual  for 
Musculoikeletal  Disease*  of  the  Upper  Limbs 

12221-0000 

Informational 

(Approved) 

CPC 

NSC 

Evaluating  Your  Workplace:  Hands  &  Anns  -  Ergonomic 
Changes  Manual 

12587-0004 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma 

15229-0000 

Informational  H 
(Approved)  | 

NPC 

ACGIH 

Ergonomic  Interventions  to  Prevent  Musculoskeletal 
Injuries  in  Industry 

9000:1987 

Informational 

(Approved) 

tPC 

ISO/EC 

Text  and  Office  Systems,  Dialog  Interaction  Part  1:  Cursor 
ConUol 

10741-1:1992 

Informational  1 
(Draft) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 
9:  Requirements  for  non-keyboard  input  device* 

9241-9 

Informational  1 
(Draft) 

NPC 

ANSI/HFS 

Human  Factors  Engineering  of  Viiual  Display  Terminal 
Workstation*  (Rev.  1 ) 

100-1988  (Revision 
1) 

Informational 
(Draft  (WD)) 

33.2.4.2  Alternative  specifications.  There  are  no  alternative  specifications  available.  Research  in 
this  area  includes  a  foot  operated  control  for  the  cursor  when  the  hands  are  occupied  (nicknamed 
a  "mole"  in  obvious  derivation  from  "mouse"). 

3.3.2.43  Standards  deficiencies.  Deficiencies  in  the  cited  standards  are  not  known. 

33.2.4.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 

33.2.4.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
non-keyboard  input  devices: 
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a.  IPO  9241-1:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  1: 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
9241  standard.  A  revised  version  of  ISO  9241-1  is  currently  at  the  CD  level  and 
will  soon  be  released  for  DIS  ballot 

b.  ISO  9241-2: 1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  presents  an  overview  of  factors  that  should  be  considered 
when  designing  tasks  to  be  performed  in  a  specific  computing  environment 

c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  —  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

d.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terms. 

e.  MIL-STD- 1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

f.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

h.  MIL-HDBK-761A  (1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

i.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

j.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

k.  ITU-T  E.134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

l.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment. 

3.3.2.4.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  non-keyboard  input  devices. 
Ergonomic  issues  for  non-keyboard  input  devices  include  keyclick,  tracking  speed,  and  on-screen 
ghosting  of  the  pointer. 

Parts  1  and  2  of  ISO  9241  are  informative.  Parts  2-9  are  expected  to  be  normative  on  completion. 
Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product.  Parts  1-8  of  ISO/IEC  9995  are  normative,  Conformance 
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with  the  overall  ISO  9995  standard  is  based  on  conformance  with  all  normative  parts  that  apply  to 
a  particular  product  Part  1  of  the  ISO/IEC  10741  standard  is  expected  to  be  normative  on 
completion. 

Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  DOD  HCI  Style  Guide  is  recommended  particularly  for  section  3,  which  covers  hardware. 
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3 32S  Human  factors  for  the  physical  environment  (This  BSA  appears  in  both  part  3,  User 
Interface,  and  part  13,  Human  Factors,)  Procurements  that  require  computing  environments  to  be 
addressed  by  ergonomic  standards  can  require  conformance  with  standards  for  illuminance,  glare, 
acoustic  noise,  the  thermal  environment  electromagnetic  emissions,  computer  workspace  design 
and  furniture  design. 

The  effects  of  low-level  non-ionized  radiation,  particularly  from  CRTs,  on  humans  have  been  a 
controversial  topic.  Ova  the  years  there  have  been  articles  advising  pregnant  women  who  have  a 
prior  history  of  miscarriage  to  stay  away  from  working  in  computa  areas.  During  the  cold  war, 
the  Soviets  were  suspected  of  secretly  bombarding  foreigners  with  non-ionized  radiation  to  study 
long  term  effects.  People  who  live  near  high  voltage  powa  lines  and  have  developed  cancer  are 
suspected  victims  of  electromagnetic  radiation.  While  there  are  no  hard  theories  to  describe  the 
relationship  between  health  problems  and  this  kind  of  radiation,  let  alone  a  standard  established. 
Some  VDT  vendors  have  made  claims  regarding  the  emissions  of  their  products  and  there  are 
aftermarket  shields  available  that  may  p. ovide  some  protection  against  this  form  of  radiation. 

Laser  printers  are  said  to  emit  ozone  during  the  printing  process.  In  an  enclosed  area,  high  levels 
of  ozone  can  be  unhealthy  or  even  toxic.  This  issue  is  still  unclear.  It  remains  to  be  seen  how 
much  ozone  is  emitted  and  what  concentrations  are  hazardous. 

3.3J.5.1  Standards.  Table  3.3-3  presents  human  factors  standards  for  the  physical  environment 


TABLE  3.3-5  Human  factors  for  the  physical  environment  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAF1M  Volume  8. 
Version  3.0: 19% 

Mandated 

(Approved) 

CPC 

QSF 

Motif  Style  Guide 

Motif  SG  Rev. 
1.2:1992 

Mandated 

(Approved) 

CPNC 

Microtoft 

The  Windowt  Interface:  An  Application  Detig n  Guide, 
Microsoft  Prett,  1992 

API  Design  Guide 

Mandated 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Facto  it 
Engineering  of  Viiual  Display  Terminal  Workstation! 

100-1988 

Informational 

(Approved) 

GPC 

DOD 

Noise  Limits  for  Military  Material 

MIL-STD-1474C 
of  8  March  1991 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  MiliUuy  Systems, 
Equipment  and  Facilities 

MIL-STD-I472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Physical  Ear  Noise  Attenuation  Testing 

MIL-STD-912of 

1 1  December  1990 

Informational 

(Approved) 

[PC 

ISO 

Ergonomic  Principles  Related  to  Menial  Work  Load  - 
General  Terms  and  Definitions 

10075:1991 

Informational 

(Approved) 

IPC 

[SO 

Principles  of  Visual  Ergonomics  -  Lighting  of  Indoor  Woik 
Systems 

8995:1989 

Informational 

(Approved) 

[PC 

ISO 

Expression  of  Users'  Requirements  Pan  i:  Thermal 
Requirements 

6242-1:1992 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Expreasioc  of  Uten'  Requirement*  Put  2i  Air  Purity 
Requirements 

6242-2:1992 

(Approved) 

IPC 

ISO 

Expieadofl  of  Uscct'  Requirements  Part  3:  Acoustical 
Requirements 

6242-3:1992 

Informational 

(Approred) 

NPC 

BA 

TEP  194,  Amd  1 
1917,  Amd  2  1988 

Informational 

(Approved) 

CPC 

NSC 

Ergonomics  in  Computerized  Office 

12223-0000 

InformationaJ 

(Approved) 

CPC 

NSC 

Guide  to  Working  Safety  with  Computers  •  Manual  (relates 
toVDTi) 

130^4-0000 

InformationaJ 

(Approved) 

CPC 

NSC 

Guide  to  Woiking  Safety  with  Computers 

13608-0000 

Informational 

(Approved) 

CPC 

NSC 

Working  Safety  with  Your  Computer 

15223-0000 

Informational 

(Approved) 

IPC 

ECMA 

Ergonomics  -  Recommendations  for  VDU  (Visual  Display 
Units)  Wotk  Pieces 

TR/22(1984) 

Informational 

(Approved) 

IPC 

ECMA 

Application  of  Human  Engineering  to  Advanced  Aircrew 
Systems 

3994  (1984) 

Informational 

(Approved) 

IPC 

ECMA 

Measurement  of  Aubome  Noise  Emitted  by  Computer  and 
Business  Equipment 

74(1992) 

Informational 

(Approved) 

IPC 

ECMA 

Measurement  of  High  Frequency  Noise  Emitted  by 
Computer  and  Business  Equipment 

108  (1989) 

Informational 

(Approved) 

IPC 

ECMA 

Declared  Noise  Emission  Values  of  Computer  and 
Business  Equipment 

109(1992) 

Informational 

(Approved) 

IPC 

ECMA 

Determination  of  Sound  Power  Levels  of  Computer  and 
Business  Equipment  Using  Sound  Intensity  Measurements; 
aiming  Method  in  Controlled  Rooms 

160(1992) 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 
Display  Terminals  (VDTs)  Part  5:  Workplace  requirements 

9241-5 

Informational 

(Draft) 

IPC 

ISO 

Ergonc*-’'-  Requirements  for  Office  Work  with  VDTi  Part 

6:  Environmental  requirements 

9241-6 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 
7:  Display  requirements  with  reflections 

9241-7 

Informational  1 

(Draft)  | 

NPC 

ANSI/HFS 

■■HigiHIHiHi 

100-1988  (Revision 
1) 

Informational  B 
(Draft  <WD))  1 

3.3.2.S.2  Alternative  specifications.  MPR  II  1990:8  (Test  Methods  for  Visual  Display  Units, 
Section  2.0.1)  is  a  Swedish  document  containing  recommended  values  for  electronic  emissions 
from  visual  display  units.  While  not  an  ISO  standard,  it  serves  as  a  de  facto  electromagnetic 
emissions  standard  for  displays  in  most  other  countries.  Many  vendors  of  monitors  claim 
compliance  with  this  or  a  similar  specification.  After-market  radiation  and  glare  shields  are  also 
available. 


3.3.2.5.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  not  known. 
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3.3.2 .5.4  Portability  caveats.  MIL-STD-1474C's  criteria  are  more  stringent  than  those  of  the 
Occupational  Safety  and  Health  Administration  and  also  covers  additional  topics  such  as 
nondetectability.  This  standard  may  be  incorporated  into  the  next  revision  of  MIL-STD-1472, 
eliminating  the  need  to  retain  MIL-STD-1474C. 

3J.2.5.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
computer  environments: 

a.  ISO  9241-1:1992,  Ergonomic  Requirements  for  Office  Work  with  VDTs,  part  1: 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
9241  standard.  A  revised  version  of  ISO  9241-1  is  at  the  CD  level  and  will  soon  be 
released  for  DIS  ballot 

b.  ANSI/ASHRAE  55,  Thermal  Environmental  Conditions  for  Human  Occupancy, 
1992. 

c.  ANSI  S  12.10-1985,  Method  for  Measurement  and  Designation  of  Noise  Emitted 
by  Computer  and  Business  Equipment 

d.  ANSIS1.13-1971,MeihodsfortheMcasurementof  Sound  Pressure  Levels. 

e.  ANSI  X5. 1-1985,  Tests  for  General  Office  Chairs. 

f.  MIL-STD- 1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

g.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems. 

h.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

i.  MIL-HDBK-761 A  (1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

j.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

k.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

l.  MIL-STD-740-1  (1986)  Airborne  Sound  Measurements  and  Acceptance  Criteria 
of  Shipboard  Equipment. 

m.  MIL-STD-740  2  (1986)  Structureborne  Vibratory  Acceleration  Measurements 
Acceptance  Criteria  of  Shipboard  Equipment 

n.  MIL-STP-1294A  (1985)  Acoustical  Noise  Limits  in  Helicopters. 
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o.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  commend 

323.2.5.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  Parts  2-9  and  12-17  are  expected  to  be  normative  on  completion. 
Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product 

The  DOD  HC1  Style  Guide  is  recommended  particularly  for  section  3,  which  covers  hardware. 
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3.3.3  GUI  client-server  operations.  Graphical  client-server  operations  define  the  relationships 
between  client  and  server  processes  operating  within  a  network;  in  particular,  graphical  user 
interface  display  processes.  The  program  that  controls  each  display  unit  is  a  server  process,  while 
independent  user  programs  are  client  processes  that  request  display  services  from  the  server, 

3.3.3.1  Data  stream  encoding.  Data  stream  encoding  provides  a  client-server  protocol  to 
interface  between  the  local  windowing  system  and  the  outside  world. 

3.3 .3.1.1  Standards.  Table  3.3-6  presents  standards  for  data  stream  encoding. 


TABLE  3.3-6  Data  stream  encoding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

User  Interface  Component  of  tbe  Application*  Portability 
Profile  (Adopt*  the  X  Protocol,  Xlib  Interface,  Xt  Intrintics, 
and  Bitmap  Diitribution  Format  of  X 1  IRS) 

FIPS  PUB  158- 

1:1993 

Mandated 

(Approved) 

CPC 

X/Optc 

X  Window  Syitem  Protocol  (X  Protocol) 

0150(7/91) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

MIT  X 
Consortium 

Data  Stream  Encoding  (X  Protocol) 

X11R6  (1994) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

GPC 

NIST 

X- Window*  User  Interface  (same  ai  in  XI 1R3) 

FIPS  PUB  158 

Informational 

(Superseded) 

3.3.3.1.2  Alternative  specifications.  The  Sun  Microsystems  XI  1/NeWS  specification  is  also 
available  for  appropriate  legacy  systems.  Users  of  X 1 1  /NeWS  need  Sun's  proprietary  "libcps" 
library  instead  of  Xlib.  (See  Data  stream  interface.) 

3.3.3. 1J  Standards  deficiencies.  A  formal  standards  effort  is  no  longer  in  progress  for  the  X 
Protocol  because  the  American  National  Standards  Institute  (ANSI  X3H3.6)  X  Protocol  effort 
has  been  disbanded.  Efforts  to  resume  its  work  have  failed  and  there  will  be  no  A.  1S1  X  Protocol 
standard.  If  the  X  Protocol  is  required  for  a  procurement,  reference  Federal  Information 
Processing  Standard  (FIPS)  158-1  (which  references  the  MIT  X  Consortium). 

As  no  significant  products  are  as  yet  available  for  the  newly  released  X 1 1R6,  the  previous 
version,  X 1 1 R5,  as  adopted  by  FIPS  158-1,  remains  as  the  accepted  secondary  reference 
standard. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  nq  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2,0  will  be  delayed  until  an  appropriate 
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threshold  of  Motif  2.0products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3 J J.  14  Portability  caveats.  System  V  Interface  Definition  (SVID)  users  with  Sun's  XI  1/NeWS 
(instead  of  the  X  Protocol)  need  Sun's  proprietary  "libcps"  library  instead  of  Xlib  (see  Data  stream 
interface). 

3JJ.1J  Related  standards.  The  following  standards  are  related  to  data  stream  encoding  or  data 
stream  encoding  standards: 

a.  ISO/IEC  JTC  1/SC18/WG9:  Working  on  a  Voice  Messaging  User  Interface 
Forum  (VMUIF).  (This  effort  moves  the  ANSI  work  of  X3V1.9  to  International 
Standard  (IS)  status.) 

b.  ANSI  X3V1.9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
Voice  Messaging  User  Interface  Forum  (VMUIF). 

c.  X  Consortium:  Data  Stream  Interface  (Xlib). 

d.  X  Consortium:  Inter-Client  Communications  Conventions  Manual  (ICCCM). 

3 .3.3. 1.6  Recommendations.  The  MIT  X  Consortium  XI  IRS  Data  Stream  Encoding  (X 
Protocol)  is  recommended  in  all  procurements  using  a  client-server  computing  architecture  in  a 
networked  environment  It  is  specified  in  FIPS  158-1  and  the  NIST  APP  (NIST  Special 
Publication  500-187).  FIPS  158-1  is  the  current  release  of  the  government  standard  which  adopts 
the  MIT  X  Consortium  XI 1R5  specification.  If  the  X  Protocol  is  required  for  a  procurement, 
provision  should  be  made  for  hard  copy  output  systems  to  be  delivered  in  a  portable  manner  or 
for  such  systems  to  be  developed  in-house. 

FIPS  158  is  the  original  version  of  this  standard  and  adopts  the  XI 1R3  specification.  It  is  included 
in  the  table  for  support  of  legacy  systems.  Motif  1.2  is  the  reference  version  of  the  OSF 
specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces. 
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33.3.2  Data  stream  interface.  The  data  stream  interface  is  a  library  of  interfaces  to  the  data 
stream  and  the  graphical  object  library.  It  is  not  to  be  confused  with  a  library  of  subroutines  which 
implements  graphical  objects  (e.g.,  Xt  Intrinsics). 

3. 3.3. 2.1  Standards.  Table  3.3-7  presents  standards  for  the  data  stream  interface. 


TABLE  3 3-7  Data  stream  interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

BliiliilSiia 

FIPS  PUB  138- 
1:1993 

Mandated 

(Approved) 

CPC 

OSF 

Motif  1.2 

Motif  1.2 

Informational 

(Approved) 

CPC 

X/Open 

XLIB  -  C  Language  Binding 

C140  (S/91) 

Informational 

(Approved) 

CPC 

MIT  X 
Consortium 

Data  Stream  Interface  (Xlib) 

XI 1R6  (1994) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

GPC 

NIST 

X- Window*  liter  Interface  (tame  aa  in  X11R3) 

FIPS  PUB  158 

Informational 

(Superseded) 

3.3.3.2.2  Alternative  specifications.  The  following  specifications  are  available  only  to  support 
legacy  systems: 

a.  Sun's  XI  1/NeWS,  which  uses  Sun's  proprietary  "libcps"  library.  This  library  is  not 
compatible  with  the  X  Consortium's  Xlib. 

b.  Application  Programming  Interface  for  Windows  (APIW). 

c.  Systems  Application  Architecture  (SAA)'s  Presentation  Manager. 

These  specifications  are  referenced  here  for  completeness  and  are  not  recommended  for  use  in 
systems  which  do  not  require  support  of  legacy  components. 

3 .3.3.2.3  Standards  deficiencies.  As  no  significant  products  are  as  yet  available  for  the  newly 
released  XI 1R6,  the  previous  version,  XI 1R5,  as  adopted  by  FIPS  158-1,  remains  as  the 
accepted  secondary  reference  standard. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1 R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 
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333.2.4  Portability  caveats.  Sun  Microsystems  "libcps"  library,  included  in  XI  1/NeWS,  is  not 
compatible  with  the  X  Consortium's  Xlib. 

3 3 .3.2 3  Related  standards.  The  Mowing  standards  are  related  :a  data  stream  interface  or  data 
stream  interface  standards: 

a.  X  Consortium:  X  Protocol. 

b.  X  Consortium:  Xt  Intrinsics. 

33.3.2.6  Recommendations.  The  MIT  X  Consortium  XI 1R5  Data  Stream  Interface  (Xlib)  is 
required  in  all  procurements  using  a  client-server  computing  architecture  with  a  graphical  user 
interface  in  a  networked  environment  It  is  specified  in  FIPS  1S8-1  and  NIST  Special  Publicatioi. 
500-187,  Application  Portability  Profile  (NIST  APP).  FIPS  158-1  is  the  current  release  of  the 
government  standard  which  adopts  the  MIT  X  Consortium  XI 1R5  specification. 

FIPS  158  is  the  original  version  of  this  standard  and  adopts  the  XI 1R3  specification.  It  is  included 
in  the  table  for  support  of  legacy  systems.  Motif  1.2  is  the  current  version  of  the  OSF 
specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces. 
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3J.3.3  Subroutine  foundation  library.  The  subroutine  foundation  library  is  a  library  of  basic 
objects  to  use  in  implementing  or  customizing  a  graphical  user  interface. 

3.3  J.3.1  Standards.  Table  3.3-8  presents  standards  for  the  subroutine  foundation  library. 


TABLE  3.3-8  Subroutine  foundation  library  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

PB?4; 

FIPS  PUB  I 58- 
1:1993 

Mandated 

(Auxoved) 

CPC 

X/Op» 

X  Toolkit  Imnonci  (Xt  lulriaiia) 

060  (7/91) 

Informational 

(Approved) 

CPC 

QSF 

Motif 

Motif  1,2 

Informational 

(Approved) 

CPC 

MIT  X 
Cotuoitiun 

Subroutine  Foundation  Library  (Xt  Inthiuics) 

X11R6  (1994) 

Infoanatiotud 

(Approved) 

CPC 

QSF 

Motif 

Motif  10 

Informational 

(Approved) 

GPC 

NIST 

. 

X-Windowi  Uaer  Interface  (ume  u  in  XI IR3) 

FIPS  PUB  158 

Informational 

(Superseded) 

33.33.2  Alternative  specifications.  The  following  proprietary  specifications  are  available  for 
support  of  legacy  systems: 

a.  XI  1/NeWS,  which  uses  Sun  Microsystems  Xview  Intrinsics,  instead  of  the  X 
Consortium's  Xt  Intrinsics. 

b.  Applications  Prc^.amming  Interface  for  Windows  (APIW)  Intrinsics. 

c.  IBM  Presentation  Manager. 

3.3.3.3J  Standards  deficiencies.  As  no  significant  products  are  as  yet  available  for  the  newly 
released  XI 1R6,  the  previous  version,  XI 1R5,  as  adopted  by  FIPS  158-1,  remains  as  the 
accepted  secondary  reference  standard. 

Motif  2.0  is  somewha,  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.3.3.4  Portability  caveats.  Sun's  Xview  Intrinsics  included  in  XI  1/NeWs,  is  not  compatible 
with  the  X  Consortium's  Xt  Intrinsics. 
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Intrinsics  from  proprietary  but  widely-used  offerings  from  Microsoft  Windows’  Presentation 
Manager,  IBM's  SAA  Presentation  Manager,  and  Apple  Computer's  Macintosh  interface  are  not 
compatible  with  one  another  or  with  Xt  Intrinsics. 

3  J .3.3.5  Related  standards.  The  following  specifications  are  related  to  the  subroutine 
foundation  library  or  subroutine  foundation  library  standards: 

a.  Open  Software  Foundation  (OSF):  Motif  High-Level  Toollcit. 

b.  X  Consortium.  Xlib. 

c.  Xview. 

d.  The  News  Toolkit  (TNT). 

3J.3.3.6  Recommendations.  The  MIT  X  Consortium  XI  IRS  Xt  Intrinsics  Subroutine 
Foundation  Library  is  recommended  in  all  procurements  using  a  client-server  computing 
architecture  with  a  graphical  user  interface  in  a  networked  environment  It  is  specified  in  FIPS 
158-1  and  the  NIST  APP.  FIPS  158-1  is  the  current  release  of  the  government  standard  which 
adopts  the  MIT  X  Consortium  XI 1R5  specification. 

FIPS  158  is  the  original  version  of  this  standard  and  adopts  the  XI 1R3  specification.  It  is  included 
in  the  table  for  support  of  legacy  systems.  Motif  1.2  is  the  reference  version  of  the  OSF 
specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces. 
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3 .3.3.4  Raster  data  interchange.  (This  BSA  appears  in  part  3,  part  S,  and  part  6.)  Raster  data 
interchange  ML  SPEC  identifies  the  requirements  to  be  met  when  raster  graphics  data 
represented  in  digital,  binary  format  are  delivered  to  the  government.  Raster  graphics  standards 
are  standards  for  pixel-by-pixel  representation  of  images.  (See  still  image  compression,  section 
3.5. 8.2,  for  more  facsimile  standards  suitable  for  raster  data  interchange.) 

3.3.3.4.1  Standards.  Table  3.3-9  presents  standards  for  raster  data  interchange. 


TABLE  3.3-9  Raster  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

Do  I) 

(Lifecycle) 

GPC 

NIST 

User  Interface  Component  of  the  Applications  Portability 
Profile  (Adopts  the  X  Protocol,  Xlib  Interface,  Xt  Intrinsic!, 
and  Bitmap  Distribution  Format  of  X11R5) 

FIPS  PUB  158* 

1:1993 

Mandated 

(Approved) 

NPC/IPC 

ANSI/I  SO/IEC 

Interfacing  Technique*  for  Dialogues  with  Graphical 
Devices  (CGI)  -  Functional  Specification  -  Part  6:  Raster 

mm 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Raster  Product  Format  (RPF) 

MIL-STD- 

2411:1994 

Mandated 

(Approved) 

IPC 

ISO/1EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  1 :  Overview  end  Fundamental  Principles  (formerly 
Product  Data  Exchange  Specification  (PDFS)) 

10303-1:1994 

Informational 

(Approved) 

CPC 

X/Op» 

X  Window  System  File  Formats  and  Application 
Conventions  (Bitmap  Dirtribubon  Format  (BDF)) 

C170  (7/91) 

Informational 

(Approved) 

GPC 

NIST 

General  Aspects  of  Group  4  Facsimile  Apparatus  (Adopts 
BIA-536-1988) 

FIPS  PUB 
149:1988 

Informational 

(Approved) 

GPC 

NIST 

Facsimile  Coding  Schemes  and  Coding  Control  Functions 
for  Group  4  Facsimile  Apparatus  (Adopts  El  A  538- 1988) 

FIPS  PUB 
150:1988 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB 
177:1992 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  1GES  Application 
Protocols 

MIL- PRF-2 8000 

Informational 

(Approved) 

OPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL- PRF-2 8002 

Informational 

(Approved) 

GPC 

DOD 

MIL-PRF-28003 

Informational  1 
(Approved) 

NPC 

ANSI/A  !IM 

Recommended  Practice;  File  Format  for  Storage  and 
Exchange  of  Images;  Bi-Level  Image  File  Format:  Part  I 

MS53-1993 

Informational 

(Approved) 

GPC 

NIST 

Standard  for  the  Interchange  of  Large  Formal  Tiled 
Documents 

NIST1R  88-4017 

Informational 

(Approved) 

IPC 

NATO 

Analogue  Video  Standard  for  Aircraft  System  Applications 

STANAG  3350 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specifications  for  ARC  Standardized  Raster 
Graphics  (ASRG) 

STANAG 

4387:1996 

Informational 

(Approved) 

IPC 

NATO 

Specifications  for  UTM/UPS  Standardized  Raster  Products 

(IJSRP) 

STANAG  7077 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Application  Profile  for  the  Interchange  of 
Formatted  Mixed  Mode  Document  •  Terminal  Equipment 
and  Protocols  for  Telematic  Services 

T.501  (1989) 

lnfomutional 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-T 

Document  Application  Profile  fof  the  Interchange  of  Group 

4  Facsimile  Document! 

T.503  (1991) 

Informational 

(Approved) 

NPC 

AUM 

Interchange  of  Tiled  Raster  Documents 

TR14:1988 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specifications  for  ARC  Digitized  Raster 
Graphics  (ADRG) 

STAN  AG  7108 

Informational 
(D raft) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IOES  Application 
Protocols 

MIL-D-28000AO) 
of  12/14/92 

Informational 

(Superseded) 

CPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Ratter  Scanned  Images) 

MQ^R-28002B(1) 
of  9/20/1993 

Informational 

(Superseded) 

33.3.4.2  Alternative  specifications.  Currently  IOES  is  the  most  mature  and  widely  implemented 
standard  for  conveying  product  data  information.  Other  bitmap  formats  include  proprietary 
formats  such  as  GIF,  PCX,  TIFF,  RLE,  and  TGA.  Except  for  support  of  legacy  products,  these 
formats  are  not  recommended. 

3.3.3.43  Standards  deficiencies.  Raster  graphics  files  require  enormous  amounts  of  storage  and 
must  be  supplemented  by  compression  standards. 

33.3.4.4  Portability  caveats.  A  standard  technique  for  raster  data  interchange  should  be  selected 
for  use  throughout  the  DOD  and  applied  wherever  possible. 

33.3.4.5  Related  standards.  The  following  standards  are  related  to  raster  data  interchange  or 
raster  data  interchange  standards: 

a.  ASME/ANSI  Y14.28M-1989,  which  describes  product  design  and  manufacturing 
information. 

b.  ITU-T,  facsimile  transmission  standards. 

c.  Raster  compression  standards, 

33.3.4.6  Recommendations.  The  mandated  standards  are  recommended  for  raster  data 
interchange. 

MIL  PRF-28002  (Raster)  can  be  used  in  a  Computer-Aided  Acquisition  and  Logistic  Support 
(CALS)  environment,  and,  when  needed,  supplemented  by  National  Institute  of  Standards  and 
Technology  Interim  Report  (N1STIR)  88-4017  (tiling).  FIPS  Pub  150  can  also  be  used.  With 
only  the  CALS  Raster  standard  available,  no  real  tailoring  guidance  is  possible.  This  version 
(MIL-PRF-28002)  supports  engineering  drawings  and  technical  manual  illustrations.  The 
previous  CALS  Raster  standard  (M1L-R-28002B)  can  be  used  for  in-place  and  unrevised  legacy 
data.  Tiling  (as  in  NISTIR  88-40 17)  and  compression  are  desirable  for  very  large  raster  graphics 
files.  (See  the  Still  image  compression  BSA,  part  3. 5. 8.2  of  the  1TSG.)  M1L-PRF-28003  (CGM) 
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offers  the  capability  for  having  raster  and  vector  graphics  in  the  same  file.  The  approved  BDF 
provides  conventions  for  font  conversion/interchange  between  external  and  internal  X  Windows 
fonts  and  can  be  used  in  procurements  using  a  client-server  computing  architecture  with  a 
graphical  user  interface  in  a  networked  environment.  BDF  can  be  compiled  in  Server  Normal 
Format  to  be  optimized  for  a  particular  server. 
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3 3 33  Communication  between  GUI  dient  applications.  Communications  between  GUI 
client  applications  is  a  functionality  of  a  windowing  system  wh  :ch  includes  the  dynamic  exchange 
of  data  and  manual  exchange  via  cut-and-paste  operations  between  windows. 

3333.1  Standards.  Table  3.3-10  presents  standards  for  communication  between  GUI  client 
applications. 


TABLE  33*10  Community 'ion  between  GUI  dient  an 

plications  standards 

Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecyde) 

CPC 

OSF 

Inter-Client  Comminkariom  Convention!  Manual 

(ICCCM) 

ICCCM  Vernon 
1.0 

Mandated 

(Approved) 

CPC 

MTTX 

Consortium 

Inter-Client  Comm  uni  c»tk  nt  Convention!  Manuel 

(ICCCM) 

ICCCM  Vernon 

1.0 

Informational 

(Approved) 

CPC 

X/Open 

Inler-Ctient  Communication!  Convention!  Manual 

(ICCCM) 

ICCM 

Informational 

(Approved) 

CJPC 

NIST 

liter  Interface  Component  of  the  APP  Inter-Client 
Communication!  Convention!  Menu.  1  (ICCCM) 

FIPS  PUB  158-2 

Informational 

(Formative) 

33.3.5.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary  (e.g.. 
Dynastic  Data  Exchange  (DDE),  Object  Linking  and  Embedding(OLE)),  and  should  be  used  only 
to  support  legacy  produ'  ts. 

3.3.3.53  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.33.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

333.53  Related  standards.  The  X  Consortium's  X  Protocol  is  a  standard  which  is  related  to 
interclient  communications  and  interclient  communications. 

3.33.5.6  Recommendations.  The  OSF ICCCM  is  recommended  in  all  procurements  using  a 
client-server  computing  architecture  with  a  graphical  user  interface  in  a  networked  environment. 

It  will  be  specified  in  FIPS  158-2.  Note  that  this  area  is  not  covered  in  FIPS  158-1.  FIPS  158-2  is 
a  formative  release  of  the  government  standard  which  adopts  the  MIT  X  Consortium  X 1 1 R6 
specification. 
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3  33.6  User  Interface  Management  System.  The  User  Interface  Management  System  (UIMS) 
is  a  CASE-like  GUI  building  tool,  which  can  be  used  to  develop  GUI-based  applications  that  are 
portable  across  platforms  with  different  appearance  and  functionality. 

333.6.1  Standards.  Table  3.3-1 1  presents  standards  for  the  user  interface  management  system. 


TABLE  33-11  User  Interface  Management  System  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Utcr  Interface  Component  of  the  Application!  Portability 
Profile  (Adopt!  the  X  Protocol.  Xlib  Interface,  Xt  Intrinrici, 
and  Bitmap  Diatribution  Fonnatof  X11R5) 

PIPS  PUB  1SS- 

1:1993 

Mandated 

(Approved) 

CPC 

QSF 

Motif  User  Interface  Management  Sy  start  (UIMS) 

Motif  1.2 

ioformatiooal 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

QSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

33.3.6.2  Alternative  specifications.  The  following  specifications  are  also  available  to  support 
legacy  systems: 

a.  Carnegie  Mellon  University  (CMU)  Software  Engineering  Institute's  (SEI)  Serpent 
UIMS  (unsupported). 

b.  NASA/Goddard  Space  Flight  Center's  (NASA)  Transportable  Application 
Environment  (TAE+)  (for  Motif,  based  on  XI 1R5). 

33.3.63  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.3.6.4  Portability  caveats.  OSF's  Motif  User  Interface  Management  System  (UIMS)  and 
USL's  Xt+  user  interface  management  systems  are  not  compatible  with  one  another. 

333.63  Related  standards.  There  are  no  related  standards. 

33.3.6.6  Recommendations.  If  a  CASE-like  GUI  applications  prototyping  tool  (set)  is  required 
for  a  procurement,  a  UIMS  should  be  acquired  that  works  with  the  proprietary  product  to  which 
it  is  matched.  No  formal  standards  efforts  are  in  progress. 
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FIPS  1S8-1  is  recommended.  It  is  the  cuirent  release  of  the  government  standard  that  adopts  the 
MIT  X  Consortium  XI 1R5  specification.  Motif  1.2  is  the  reference  version  of  the  OSF 
specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces. 
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3 3.3.7  Data  interchange  format  for  GUI-based  applications.  A  data  interchange  format  for 
GUI-based  applications  allows  data  to  be  exchanged  via  a  standard  format  between  applications 
using  different  GUIs. 

333.7.1  Standards.  Table  3.3-12  presents  standards  for  a  data  interchange  format  for  GUI- 
based  applications. 


TABLE  33-12  Data  interchange  format  for  GUI-based  applications  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mu 

CPC 

QSF 

Intor-Qknt  Communkatiooi  Convention  Manual 

(ICCCM) 

ICCCM  Vmioo 

1.0 

Mandated 

(Approved) 

CPC 

fcflTX 

Consortium 

Inter-Ctieat  Communication!  Convention*  Manual 

(ICCCM) 

ICCCM  Vernon 

1.0 

Informational 

(Approved) 

CPC 

MUX 

Cooaortium 

Inter-Client  Communication!  Convention!  Manual 

(ICCCM) 

ICCCM  (XUR6) 

Informational 

(Approved) 

CPC 

QSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

GPC 

NIST 

liter  Interface  Component  of  the  APP  Inter-Cbent 
Communication!  Convention!  Manual  (ICCCM) 

FIPS  PUB  1SS-2 

Informational 

(Formative) 

33.3.7.2  Alternative  specifications.  The  legacy  supporting  specification  available  is  the 
Application  Programming  Interface  for  Windows  (APIW):  Dynamic  Data  Exchange  (DDE). 

333.73  Standards  deficiencies.  The  MIT  X  Consortium’s  ICCCM  provides  incomplete 
coverage,  but  now  defines  interapplication  drag  and  drop. 

As  no  significant  products  are  as  yet  available  for  the  newly  released  XI 1R6,  the  previous 
version,  XI 1R5,  as  adopted  by  FIPS  158-1,  remains  as  the  accepted  secondary  reference 
standard. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflict;  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.3.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

33.3.7.5  Related  standards.  The  X  Consortium's  X  Protocol  is  related  to  data  interchange 
formats  for  GUI-based  applications. 
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3-3J.7.6  Recommendations.  The  OSF ICCCM  is  recommended  in  all  procurements  using  a 
client-server  computing  architecture  with  a  graphical  user  interface  in  a  networked  environment 
It  will  be  specified  in  FIPS  158-2.  Note  that  this  area  is  not  covered  in  FIPS  158-1.  FIPS  \  58-2  is 
a  formative  release  of  the  government  standard  which  adopts  the  MIT  X  Consortium  XI 1R6 
specification. 

If  a  standard  data  interchange  format  for  data  to  be  exchanged  between  applications  using 
different  GUIs  is  needed,  no  complete  specification  is  available.  Some  capability  is  provided  in 
MIT's  ICCCM  for  X  Windows-based  systems,  while  APIW-based  applications  can  exchange  data 
between  conforming  applications  using  MS's  DDE  software. 
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3.3. 3.8  X  Logical  Font  Description.  The  X  logical  font  description  is  a  format  for  fonts  in  use  in 
the  X  Windows  System. 

3.33.8.1  Standards.  Table  3.3-13  presents  standards  for  X  logical  font  description. 


TABLE  33-13  X  Logical  Font  Description  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

CPC 

X/Opm 

X  Logic*]  Font  Description  (XLFD) 

XLFD  Venice  1.3 

Adopted 

(Approved) 

CPC 

MIT  X 
Cojuoftium 

X  Logic*]  Font  Description  (XLFD) 

XLFD  Venion  1.3 

Informed  oo*] 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informed  oo*] 
(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Infotmedonel 

(Approved) 

3333.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

333.83  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.3.8.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

333.83  Related  standards.  The  X  Consortium's  X  Window  System  is  related  to  X  Logical 
Font  Description. 

33.3.8.6  Recommendations.  The  X  Logical  Font  Description  (XLFD)  is  recommended  to 
provide  standardized  conventions  for  client  applications  to  query  and  access  fonts  across  all  X 
servers  in  a  procurement  Motif  1.2  is  the  reference  version  of  the  OSF  specification  for  GUI 
behavior  and  appearance  and  programming  and  data  interfaces.  This  standard  equivalently 
includes  the  X  Logical  Font  Description. 
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3.3 .3.9  Compound  text  encoding.  A  compound  document  is  composed  of  a  variety  of  data 
types  and  formats.  Each  data  type  is  linked  to  the  application  used  to  create  it.  A  compound 
document  might  include  audio,  video,  images,  text,  and  graphics. 

3. 3-3. 9.1  Standards.  Table  3.3-14  presents  standards  for  compound  text  encoding. 


TABLE  3.3-14  Compound  text  encoding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

JOOpcc 

Compound  Text  Encoding  (CTE) 

CTE  Venioa  1.1 

Adopted 

(Approved) 

CPC 

MIT  X 
Consortium 

Compokmd  Text  Encoding  (CTE) 

CTE  Vernon  1.1 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  10 

Informational 

(Approved) 

3  J.3.9.2  Alternative  specifications.  No  other  specifications  are  available. 

3J.3.9 3  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Vlotif  2.0  and 
XI 1R6  arc  resolved. 

3.3.3.9.4  Portability  caveats.  OSF's  Motif  support  of  two  CTEs  can  result  in  portability 
problems. 

3.3.3.9.5  Related  standards.  The  X  Consortium's  X  Window  System  is  related  to  compound  text 
encoding. 

3.3.3.9.6  Recommendations.  The  CTE  for  a  standards-based  X  Windows  interchange  format  for 
multiple  character  sets  in  a  procurement  is  recommended.  Motif  1 .2  is  the  current  version  of  the 
OSF  specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces.  This 
standard  equivalently  specifies  a  Compound  Text  Encoding  standard. 
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3 .3.3.10  Uniform  API.  A  uniform  GUI  API  toolkit  is  a  software  library  defining  a  layer  between 
application  specific  code  and  a  system  specific  GUI  code,  as  defined  by  a  platform  or  system 
specific  toolkit  (API).  It  does  not  directly  provide  window  or  graphics  support,  but  it  should 
allow  software  developers  to  write  their  applications  to  one  common  interface  regardless  of  the 
underlying  (native)  GUI  of  a  particular  system  or  platform. 

3.3  J.  10.1  Standards.  Table  3.3-15  presents  standards  for  a  uniform  API. 


TABLE  3.3-15  Uniform  API  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NM 

N.A. 

None 

N.A. 

InformationaJ 

(N.A.) 

3.3.3.10.2  Alternative  specifications.  The  following  specifications  are  available: 

a.  Planning  Research  Corporation's  (PRC)  THINGS  (The  Higher-Level  Interface- 
Non-GUI  Specific):  A  public  domain  specification  developed  under  a  U.  S.  Air 
Force  Contract. 

b.  TAE  Plus  (Transportable  Applications  Environment  Pius):  A  public  domain 
window  programming  tools  specification  developed  by  the  NASA/Goddard  Space 
Flight  Center  and  Century  Computing,  Inc. 

3.3.3. 10  J  Standards  deficiencies.  No  standards  exist  for  UAPIs. 

3.3.3.10.4  Portability  caveats.  All  existing  UAPIs  are  proprietary  products.  There  are  no 
standards  for  their  implementation. 

3.3.3.10.5  Related  standards.  The  following  standards  are  related  to  GUI  uniform  toolkit  APIs: 

a.  IEEE  P1201.2:  Drivability  (recommended  practice,  in  ballot). 

b.  OSF:  Motif. 

3.3.3.10.6  Recommendations.  The  IEEE  PI 20 1.1  working  group,  which  was  attempting  to 
produce  a  standard  in  this  area,  has  disbanded.  There  is  a  lack  of  interest  in  this  area  by  the 
commercial  software  community.  A  number  of  proprietary  products  are  available  for  the 
development  of  cross-platform  applications  based  upon  a  uniform  API.  All  existing  UAPIs  are 
proprietary  products.  There  are  no  standards  for  their  implementation.  If  a  proprietary  UAPI 
toolkit  must  be  selected,  one  supporting  Ada  should  be  chosen. 
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3JJ.il  X  Windows  over  OSI.  (This  BSA  appears  in  part  3  and  part  1 1.)  These  are  standards 
for  implementing  the  X  Window  System  in  an  application  running  on  the  Open  Systems 
Interconnection  (OSI)  protocol  stack. 

3JJ.11.1  Standards.  Table  3.3-16  presents  standards  for  X  Windows  over  OSI. 


TABLE  3  J- 16  X  Windows  over  OSI  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

MIT  X 
Cooiortim 

X  Window*  Over  OSI 

X11R6 

Informational 

(Formative) 

3J.3.1U  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 


3J.3.11J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3J.3.11.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3J.3.11J  Related  standards.  The  following  standards  are  related  to  implementing  X  Windows 
over  the  OSI  stack: 

a.  X  Consortium:  X  Window  System. 

b.  ISO:  OSI  Stack. 

3.3.3.11.6  Recommendations.  No  formal  standard  is  available  to  support  a  procurement  for  X 
Windows  running  on  the  OSI  stack  and  none  is  in  progress.  The  MIT  X  Consortium  intends  to 
incorporate  a  version  of  the  European  Workshop  for  Open  Systems  (EWOS)  X  Windows  over 
OSI  specification  in  a  future  XI 1  release  (XI 1R6),  which  probably  will  be  adopted  by  X/Open 
and  appear  in  a  future  version  of  FIPS  146,  the  Government  Open  Systems  Interconnection 
Profile.  The  manner  in  which  XI 1R6  handles  "safe  threading"  to  support  multi-threaded 
applications  is  inconsistent  with  the  Motif  2.0  standard,  which  is  based  upon  XI 1R5.  Motif  2.0 
will  execute  on  XI 1R6,  but  thread-safe  operation  is  not  assured.  XI 1 R6  is  the  current  version  of 
the  X  Windows  Version  1 1  GUI  standard. 
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3.3.4  Object  definition  and  management  GUI  object  definitions  are  display  objects 
specifications  that  define  characteristics  of  display  elements  such  as  color,  shape,  size,  movement 
graphics  context  user  preferences,  interactions  among  display  elements. 

3  J.4.1  Application  programming  interfaces.  An  application  programming  interface  (API)  is  a 
library  of  predefined  higher-level  objects  which  defines  a  programming  "layer"  to  facilitate 
development  of  applications.  A  GUI  API  usually  is  designed  to  implement  a  GUI  for  a  particular 
environment  and,  therefore,  may  not  produce  portable  applications.  A  uniform  GUI  API  supports 
common  functionality  across  operating  systems  and  platforms  specifically  to  promote  portability. 

3.3.4.1.1  Standards.  Table  3.3-17  presents  standards  for  application  programming  interfaces. 


TABLE  3.3-17  Application  programming  interfaces  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDE  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Dwlrlop  Environment  (CDE);  XCDE  Definition* 
and  Infra*  nurture 

C324  (4/95) 

Mandated 

(Approved) 

NPC 

rppp 

Modular  Toolkit  Environment  (MTE) 

1295:1993 

Informational 

(Approved) 

IPC 

ECMA 

Application  Programming  Interface  for  Window*  (APIW) 

234  (1995) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif 10 

Informational 

(Approved) 

CPC 

OSF 

CDEneat/Motif  (CDE/Motif  under  OSF  Preatiuctured 
Technology  (PST)) 

CDE/MotifPST 

Emerging 

(Foimative) 

3.3.4.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary  and 
should  only  be  used  to  support  legacy  software. 

3.3.4. 1J  Standards  deficiencies.  Formal  and  government  standards  will  not  be  available  in  the 
near-to-medium  term. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2,0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  is  resolved. 

3.3.4.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
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3.3. 4. 1.5  Related  standards.  The  following  standards  are  related  to  APIs  or  API  standards: 

a.  ISO/IEC  JTC  1/SC18/WG9:  Working  on  a  VMU1F.  (This  effort  moves  the  ANSI 
work  of  X3V1.9  to  ISO  status.)  The  group  also  is  developing  standards  for  user 
interfaces  and  symbols  associated  with  text  and  office  systems.) 

b.  ISO  DIS  11730  F1MS. 

c.  ANSI  X3V1.9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
VMUIF. 


3.3.4. 1.6  Recommendations.  The  Common  Desktop  Environment  (CDE)  is  recommended. 

CDE  is  a  unified  UNIX  interface  based  on  a  highly  customized  Motif  toolkit  Initially  developed 
by  the  Common  Open  Software  Environment  (COSE),  it  is  now  part  of  a  unified,  vendor-neutral 
development  of  CDE,  Motif,  and  the  X  Window  System  under  the  X  Consortium,  CDE  provides 
a  more  modem  and  robust  GUI  interface  than  Motif  for  POSIX  platforms  as  well  as  a  more 
robust  development  environment.  CDE  is  found  in  two  companion  documents,  C323  and  C324. 

The  IEEE  1295  standard  is  based  upon  a  C  language  binding  to  Motif.  A  number  of  products  are 
available  which  support  the  development  of  applications  usmg  an  IEEE  1295  like  Ada  API 
interface.  An  IEEE  study  group  is  currently  beginning  the  process  of  specifying  an  Ada-95 
binding  to  MTE  (IEEE  1295)  and  Modf.  IEEE  1295  adopts  the  C  language  toolkit  defined  by  the 
OSF/Motif  1.2  specification.  Motif  1.2  is  the  current  version  of  the  OSF  specification  for  GUI 
behavior  and  appearance  and  programming  and  data  interfaces. 

An  ECMA  working  group  has  developed  an  API  specification  for  Windows  based  upon  MS 
Windows  3.1  functionality.  This  specification  will  provide  an  ISO  open  standard  for  interfacing  to 
MS  Windows  and  similar  alternate  GUIs. 
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33.42  User  Interface  Definition  Language.  A  User  Interface  Language  (UIL)  is  a  rapid 
prototyping  tool  that  simplifies  programming  of  GUI-based  applications.  It  allows  application 
developers  to  create  a  file  containing  a  high-level  description  of  an  interface's  graphical  objects 
and  resources. 

3.3.4.2.1  Standards.  Table  3.3-18  presents  standards  for  user  interface  definition  language. 


TABLE  33-18  User  Interface  Definition  Language  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Motif  Uur  Interface  Language  (UIL) 

Motif  AES  1.2 

Mandated 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

33.4.2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary  and 
are  not  recommended  except  in  support  of  legacy  systems. 

33.4.23  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.4.2.4  Portability  caveats.  The  OSF  Motif  User  Interface  Language  (UIL)AJser  Interface 
Management  Services  (UIMS)  and  the  USL  Xt+  user  interface  definition  languages  are  not 
compatible  with  one  another. 

33.4.2.5  Related  standards.  The  only  other  available  specifications  are  proprietary. 

33.4.2.6  Recommendations.  Motif  UIL  is  recommended.  A  UIL  usually  is  contained  within  a 
UIMS.  A  UIMS  may  contain  a  UIL  with  additional  tools.  Motif  1 .2  is  the  current  version  of  the 
OSF  specification  for  GUI  behavior  and  appearance  and  programming  and  data  interfaces.  It 
includes  the  specification  of  the  UIL. 
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3-3.4J  Graphical  user  interface  style  guides.  A  GUI's  style  guide,  which  is  part  of  the 
presentation  management  layer  in  the  NISTs  User  Interface  Reference  Model,  specifies  a 
standard  "look"  for  the  GUI  of  an  application  to  the  user. 

3.3.4.3.1  Standards.  Table  3.3-19  presents  graphical  user  interface  style  guides. 


TABLE  3.3-19  Graphical  user  interface  style  guides  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif  Style  Guide 

Motif  SO  Rev. 
1.2:1992 

Mandated 

(Approved) 

NPC 

ANSI/HFS 

America!}  National  Standard  for  Human  Futon 
Engineering  of  Visual  Display  Terminal  Woifcrtations 

100-1988 

Informational 

(Approved) 

IPC 

NATO 

Principles  of  Presentation  of  Information  in  Aircrew 
Stations 

STANAO  3705 

Informational 

(Approved) 

GPC 

DOD 

User/Computer  Interface 

MIL- STD- 1801  29 
May  1987 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Performance  Requirements  for 
Systems 

MIL-STD-1800A 

10  Oct.  1990 

Informational 

(Approved) 

GPC 

DOD 

DOD  Handbook,  Human  Engineering  Guidelines  for 
Management  Information  Systems 

MIL-HDBK-761A 
30  Sep.  1989 

Informational 

(Approved) 

GPC 

DOD 

Guidelines  for  Designing  User  Interface  Software 

ESD-TR- 86-278 

Informational 

(Approved) 

GPC 

DOD 

Air  Force  Intelligence  Data  Handling  System  (IDHS)  Style 
Guide 

IDHS  Style  Guide 

1990 

Informational 

(Approved) 

GPC 

DOD 

Human  Facto n  Guidelines  for  the  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier- Machine 
Interface 

ATCCS  Guidelines 
v.i.Oandv.2.0, 
1990  and  1992 

Informational 

(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS,  Version 
1.1. 1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

M1L-STD-1472D 
Notice  2.  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Guidelines  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

Informational 

(Approved) 

GPC 

DOD 

MIL-STD  46855B 
26  May  1994 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

GPC 

DOD 

Department  of  Defense  Intelligence  Information  Systems 
Style  Guide 

Informational 

(Approved) 

IK' 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 
10:  Dialogue  principles 

9241-10:1996 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 

1 1:  Guidance  on  usability  specifications  and  measures 

9241-11 

Informational 

(Draft) 

LPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 

12:  Presentation  of  information 

9241-12 

Informational 

(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO 

Ergonomic  Requirement!  for  Office  Work  with  VDTs  Put 
13:  liter  guidance 

9241-13 

Informational 

(Drift) 

IPC 

ISO 

Ergonomic  Requirement!  for  Office  Work  with  VDTs  Part 
14:  Menu  dialogs 

9241-14 

Informational 

(Draft) 

IPC 

ISO 

9241-15 

informational 

(Dnft) 

IPC 

ISO 

Ergonomic  Requirement!  for  Officer  Work  with  VDTi  Part 
16:  Direct  manipulation  dialogs 

9241-16 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  Requirement!  for  Office  Work  with  VDTi  Part 
17:  Fortn-fillinf  dialog! 

9241-17 

Informational 

(Draft) 

IPC 

ISO/IEC 

Graphical  Symbol!  Used  on  Screem:  Interactive  Icon! 

11581 

Informational 
(Draft  (CD)) 

NPC 

rppF. 

Recommended  Practice  for  Graphical  liter  Interface 
Drivability 

P1201.2 

Informational 
(Draft  (Project 
being  canceled,  lack 
of  progreii)) 

GPC 

DOD 

Joint  Satellite  Control  (JSC)  Human  Computer  Interface 
Standard,  Veraion  1.0 

JSC  Ha  Std..  1.0 

Informational 

(Draft) 

33.43.2  Alternative  specifications.  Several  applicable  consortia  or  de  facto  style  guides  are 
available  for  software  user  interfaces.  These  style  guides  promote  consistency  in  user  interface 
design  across  applications.  However,  conformance  with  one  or  more  the  style  guides  listed  below 
does  not  guarantee  conformance  with  ergonomic  standards  (e.g.,  ISO  9241).  These  style  guides 
include: 

a.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft) 

b.  Object-Oriented  Interface  design:  IBM  Common  User  Access  Guidelines  (IBM) 

c.  Macintosh  Human  Interface  Guidelines  (Apple  Computer) 

d.  SAA  Presentation  Manager  Style  Guide/  Common  User  Access  (CUA)  (IBM) 

e.  Standard  User  Interface  Style  Guide  for  Compartmented  Mode  Workstations 
(Defense  Intelligence  Agency  (D1A)) 

f.  Compartmented  Mode  Workstation  Labeling:  Source  Code  and  User  Interface 
Guidelines  (DLA) 

g.  Air  Force  Standard  Systems  Center  GUI  Style  Guide,  SSCR  700-10,  Vol  1 

h.  User  Interface  Specifications  for  the  Global  Command  and  Control  System 
(GCCS),  Version  1.0,  draft,  October  1994 

i.  Theater  Battle  Management  Style  Guide  (U.S.  Navy) 
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j.  Army  Theater  Battle  Management  HCI  Specification 

It.  Navy  JMCIS. 

33.4.3.3  Standards  deficiencies.  Currently,  conformance  to  parts  12-17  of  the  ISO  9241 
standard  is  on  a  part-by-part  basis.  There  is  concern  that  the  overall  standard  may  thus  fail  to 
address  potential  ergonomic  problems  arising  from  interactions  between  the  user  interface 
elements  covered  by  the  individual  parts. 

There  is  concern  that  ISO/IEC  1 1581  may  contain  overly  rigid  specifications  for  the  set  of  icon 
shapes  that  can  be  used  to  represent  different  user  interface  parts. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  produc  s  are  as  yet  available  for  Motif  2.0,  the  previous  version.  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.4.3.4  Portability  caveats.  NIST  FIPS  158-1  (User  Interface  Component  of  the  Applications 
Portability  Profile)  mandates  the  use  of  the  X  Window  protocol,  X  library,  and  X  toolkit 
intrinsics.  IEEE  P1201.2,  when  completed,  is  intended  to  increase  the  level  of  user  interface 
consistency  (and  thus  user  interface  portability)  across  X  Windows-based  enviroi  ments.  There  are 
potential  conflicts  here. 

DOD  HCI  Style  Guide  is  based  on  (and  intended  to  supersede)  the  Army,  Navy,  Air  Force,  and 
DODIIS  style  guides  cited  in  the  table  above.  The  goal  of  this  effort  is  to  minimise  unnecessary 
user  interface  diversity  across  DOD  systems.  There  are  potential  problems  with  systems  designed 
to  accommodate  different  style  guides. 

MIL-STD-1800  is  an  Air  Force-only  standard  that  duplicates  M1L-STD-1472D  und  is  largely 
ignored  in  Air  Force  acquisitions.  It  has  been  recommended  that  MIL-STD-1800  be  canceled  and 
any  value  added  material  be  added  to  MIL-STD-1472D. 

3.3.4.33  Related  standards.  The  following  standards  are  related  to  user  interface  style  guides: 

a.  ISO  9241  - 1 :  i  992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  1 : 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
9241  standard.  A  revir  version  of  ISO  9241-1  is  currently  at  the  CD  level  and 
will  soon  be  released  for  D1S  ballot 

b.  ISO  9241-2: 1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  present  an  overview  of  factors  that  should  be  considered  when 
designing  tasks  to  be  performed  in  a  specific  computing  environment. 
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c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  -  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  s  rms  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-  being,  performance,  and  effectiveness. 

d.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terms. 

e.  NIST  FIPS  158-1,  User  Interface  Component  of  the  Applications  Portability 
Profile. 

f.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

h.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

i.  DOD-HDBK-743A  (19S 1)  Anthropometry  of  U.S.  Military  Personnel. 

j.  ITU-T  E.134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

k.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment. 

3.3.4.3.6  Recommendations.  A  style  guide  is  necessary  for  development  of  all  GUIs.  There  are 
no  formal  standards  efforts  in  this  area.  A  style  guide  is  part  of  the  Presentation  Layer  in  NIST 
FIPS  158-1.  Procurements  that  require  software  user  interfaces  to  be  addi  jssed  by  ergonomic 
standards  can  require  conformance  with  standards  for  menu  structures,  command  languages, 
direct  manipulation  dialogs,  forms-based  dialogs,  windowing,  'cons,  screen  formatting, 
information  coding,  and  user  guidance. 

It  is  recommended  that  the  practices  of  the  DOD  HCI  Style  Guide,  TAFIM,  Volume  8  be 
followed.  It  provides  a  commo'  framework  for  HCI  design  and  implementation  with  emphasis  on 
standard  look  and  feel  for  GUi  ..used  applications.  As  many  aspects  of  standard  GUI  style  are 
application  specific,  application  area  style  guides  should  also  be  used  when  available.  Motif  1.2  is 
the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and  programming 
and  data  interfaces.  It  includes  a  style  guide  for  GUI  interfaces  and  is  also  recommended. 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative;  parts  10  and  1 1  are  expected  to  be 
informative  on  completion.  Parts  12-17  are  expected  to  be  normative  on  completion. 

Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product.  The  ISO/IEC  11581  standard  is  expected  to  be  normative 
on  completion. 
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33.4.4  Three-dimensional  appearance.  Modem,  color  GUI  applications  make  use  of  a  three- 
dimensional  appearance  which  is  more  pleasing  to  the  user  than  the  older  two-dimensional 
appearance  of  monochrome  GUIs. 

3.3.4.4.1  Standards.  Table  3.3-20  presents  standards  for  three-dimensional  appearance. 


TABLE  3.3-20  Three-dimensional  appearance  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

Uaer  Interface  Component  of  the  Application*  Portability 
Profile  (Adopt*  the  X  Protocol,  Xlib  Interface,  Xt  Intrinsic*, 
and  Bitmap  Distribution  Format  of  XI 1R5) 

FIPS  PUB  1'"’- 

1:1993 

Mandated 

(Approved) 

CPC 

MTTX 

Cooaoitium 

X  Cooaoitium'*  PHIGS-bued  3-D  Extension  to  the  X 
Window  System  (PEX) 

X11R5 

Informational 

(Approved) 

CPC 

MITX 

Consortium 

X  Consortium's  PHIGS -baaed  3-D  Extension  to  X  Window 
System  (PEX) 

X11R6 

Informational 

(Approved) 

33.4.4.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

33.4.43  Standards  deficiencies.  As  no  significant  products  are  as  yet  available  for  the  newly 
released  XI 1R6,  the  previous  version,  XI 1R5,  as  adopted  by  FIPS  158-1,  remains  as  the 
accepted  secondary  reference  standard. 

33.4.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

33.4.4.5  Related  standards.  The  standard  related  to  integration  of  3-D  graphics  with  GUIs  is 
ISO  9592-1,  -2,  -3:  PHIGS  (Programmers  Hierarchical  Interactive  Graphics  System). 

33.4.4.6  Recomni"':;  J.  lions.  Conformance  to  FIPS  158-1,  which  subsumes  PHIGS  Extension  to 

X  (PEX),  is  requi  .i-  '-D  extensions  to  X  Windows  based  on  the  PHIGS  graphics  standard 

(ISO  9592)  are  needed.  FIPS  158-1  is  the  current  release  of  the  government  standard  which 
adopts  the  MIT  X  Consortium  XI 1R5  specification.  These  standards  specify  the  PHIGS 
Extension  to  X  Windows  (PEX). 
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3 .3.4 £  Interchange  format  for  design  tools.  A  common,  GUI-independent  Interchange  Format 
for  Interactive  Design  Tools  (IDTIF)  would  allow  different  tools  for  developing  interactive 
graphical  windowing  applications  to  exchange  graphic  objects  and  basic  screen  information. 

3.3.4.5.1  Standards.  Table  3.3-21  presents  standards  for  interchange  formats  for  design  tools. 


TABLE  3.3-21  Interchange  format  for  design  tools  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

CPC 

X/Op KB 

Common  Desktop  Environment  (CM);  XCDE  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(ARROved) 

CPC 

XJOpto 

Common  Deaktop  Environment  (CDE);  XCDE  Definition* 
and  Infrastructure 

C3*4  (4/95) 

Mandated 

(Approved) 

CPC 

QSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

CPC 

QSF 

OSF  U*er  Interface  Management  Sytletn  (UIMS)  Working 
Group 

UIMS  WG 

Informational 

(Formative) 

CPC 

OSF 

CDEncxt/Motif  (CDE/Motif  under  OSF  PretUuctured 
Technology  (PST)) 

CDE/Motif  PST 

Emerging 

(Formative) 

3.3.4 .5.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3J.4.5 3  Standards  deficiencies.  Interactive  Design  Tools  (IDT)  that  want  to  interchange 
graphic  objects  and  screen  information  need  a  common  GUI-independent  Interchange  Format 
(IF).  There  are  few  of  these  tools  (IDTs),  and  they  do  not  have  a  common  IDTIF.  Deficiencies  in 
the  standards  are  unknown,  since  these  services  are  not  part  of  any  formal  standard. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.4.5.4  Portability  caveats.  Portability  problems  with  the  existing  specification  are  unknown. 

3.3.4.5.5  Related  standards.  No  standards  are  related  to  design  tool  interchange  format 
standards. 

3.3.4.5.6  Recommendations.  Consortia  work  on  IDTIF  specifications  is  in  the  early  stages. 
Tools  must  be  procured  for  specific  GUIs,  and  these  cannot  work  with  tools  for  other  GUIs. 
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The  Common  Desktop  Environment  (CDE)  is  recommended.  CDE  is  a  unified  UNIX  interface 
based  on  a  highly  customized  Motif  toolkit.  Initially  developed  by  the  Common  Open  Software 
Environment  (COSE),  it  is  now  part  of  a  unified,  vendor-neutral  development  of  CDE,  Motif,  and 
the  X  Window  System  under  the  X  Consortium.  CDE  provides  a  more  modem  and  robust  GUI 
interface  than  Motif  for  POSIX  platforms  as  well  as  a  more  robust  development  environment 
CDE  is  found  in  two  companion  documents,  C323  and  C324. 


April  7,  1997 


3.3-49 


Version  3. 1 


3 3.4.6  Customization  to  local  norms.  (This  BSA  appears  in  part  3,  User  Interface,  part  13, 
Human  Factors,  and  part  14,  Internationalization.)  Customization  to  local  norms  involves 
modification  of  die  key  mapping  to  accommodate  the  local  language  and  display  of  data  in  the 
commonly-used  format  (e.g.,  numbers,  dates,  rime). 

3. 3. 4. 6.1  Standards.  Table  3.3-22  presents  standards  for  customization  to  local  norms. 


TABLE  3.3-22  Customization  to  local  norms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

Dol) 

(Lifecycle) 

GPC 

DOD 

Human-Computer  Interface  (HCI)  Style  Guide 

TAF1M  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

X/Open 

Interoatioiuliution  Guide,  version  2 

G304  (7/93) 

Informational 

(Approved) 

CPC 

X/Opcn 

Locale  Registry  Procedures 

G303  (1993) 

Informational 

(Approved) 

CPC 

QSF 

Motif  1.2  (continent  with  X/Open's  NLS  specifications  & 
also  double-byte  character  sea) 

Motif  1.2 

Informational 

(Approved) 

CPC 

MIT  X 
Consortium 

X  Window  System  (X  font  manager-  includes  double-byte 
character  sea) 

X11R5 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

GPC 

DOD 

Military  Standard  Keyboard  Arrangements 

MIL-STD-1280, 
Notice  1.  1969 

Informational 

(Approved) 

GPC 

DOD 

User/Computer  Interface 

MIL-STD-1801  29 
May  1987 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Performance  Requirements  for 
Systems 

M1L-STD-1800A 

10  Oct.  1990 

[nfo.mational 

(Approved) 

GPC 

DOD 

DOD  Handbook,  Human  Engineering  Guidelines  for 
Management  Information  Systems 

MIL-HDBK-76IA 
30  Sep.  1989 

Informational 

(Approved) 

GPC 

DOD 

Guidelines  for  Designing  User  Interface  Software 

ESD-TR-86-278 

Informational 

(Approved) 

GPC 

DOD 

Department  of  Defense  Intelligence  Information  Systems 
Style  Guide 

DODI1S  Style 
Guide.  10/91 

Informational 

(Approved) 

GPC 

DOD 

Air  Force  Intelligence  Data  Handling  System  (1DHS)  Style 
Guide 

IDHS  Style  Guide 
1990 

Informational 

(Approved) 

GPC 

DOD 

Human  Factors  Guidelines  for  the  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier- Machine 
Interface 

ATCCS  Guidelines 
v.  1.0  and  v.2.0, 
1990  and  1992 

Informational 

(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS,  Version 
1.1.  1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

M1L-STD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Guidelines  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

Informational 

(Approved) 

CPC 

X/Open 

Distributed  Internationalisation  Services 

S213  (11/92) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Opai 

Internationalisation  of  Internetworking  Specification* 

S302  (4/93) 

Informational 

(Approved) 

CPC 

X/Open 

File  System  Safe  UCS  Transformation  Format  (FSS-UTF) 

P316  (1993) 

Informational 

(Approved) 

CPC 

X/Open 

System  Interface  and  Headers,  Issue  3 

C212  (3/92) 

Informational 

(Approved) 

CPC 

X/Open 

Supplement!.;  Definitions,  Issue  3 

C213  (3/92) 

Informational 

(Approved) 

CPC 

X/Open 

Universal  Multiple-Octet  Coded  Character  Set  Coexistence 
and  Migration 

E401  (3/94) 

Informational 

(Approved) 

NPC 

ANSI/S  AE 

Human  Interface  Design  Methodology  for  Integrated 
Display  Symbology 

ARP  4 155  (1990) 

Informational 

(Approved) 

GPC 

DOD 

MIL-STD-46855 B 
26  May  1994 

Informational 

(Approved) 

CPC 

X/Open 

Single  Unix  Specification  (Spec.  1 170),  System  Interface 
Definitions,  Issue  4,  Version  2  (part  of  XPG4) 

C434  (9/94) 

Informational 

(Approved) 

CPC 

X/Open 

Single  Unix  Specification  (Spec.  1 170),  System  Interfaces 
and  Hewers,  Issue  4,  Version  2,  (Part  of  XPG4) 

C435  (9/94) 

Informational 

(Approved) 

CPC 

X/Ope* 

Locale  Registry  Procedures,  Vernon  2 

G502  (5/95) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

CPC 

X/Open 

Internationalisation  Guide,  Version  3 

0503  (11/95) 

Informational 

(TBD) 

IPC 

ISO 

9241-11 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 

12:  Preaent-uon  of  information 

9241-12 

Informational 

(Draft) 

NPC 

IEEE 

Recommended  Practice  for  Graphical  User  Interface 
Drivability 

PI201.2 

Informational 
(Draft  (Project 
being  canceled,  lack 
of  progress)) 

GPC 

DOD 

Joint  Satellite  Control  (JSC)  Human  Computer  Interface 
Standard,  Version  1.0 

JSC  HCI  Std..  1.0 

Informational 

(Draft) 

3.3.4.C.2  Alternative  specifications.  Several  applicable  consortia  or  de  facto  style  guides  are 
available  for  internationalization.  However,  conformance  with  one  or  more  the  style  guides  listed 
below  does  not  guarantee  conformance  with  ergonomic  standards: 

a.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft) 

b.  Object-Oriented  Interface  design:  IBM  Common  User  Access  Guidelines  (IBM) 

c.  Macintosh  Human  Interface  Guidelines  (Apple  Computer). 

3.3.4.6.3  Standards  deficiencies.  Currently,  conformance  to  parts  12-17  of  the  ISO  9241 
standard  is  on  a  part-by-part  basis.  There  is  concern  that  the  overall  standard  may  thus  fail  to 
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address  potential  ergonomic  problems  arising  from  interactions  between  the  user  interface 
elements  covered  by  the  individual  parts. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.4.6.4  Portability  caveats.  Although  Motif  supports  the  X/Open  Native  Language  System,  it 
also  supports  a  number  of  its  own  internationalization  extensions  which  makes  it  incompatible 
with  some  legacy  specifications. 

NIST  FIPS  158-1  (User  Interface  Component  of  the  Applications  Portability  Profile)  mandates 
the  use  of  the  X  Window  protocol,  X  library,  and  X  toolkit  intrinsics.  IEEE  P1201.2,  when 
completed,  is  intended  to  increase  the  level  of  user  interface  consistency  (and  thus  user  interface 
portability)  across  X  Windows-based  environments.  There  are  potential  conflicts  here. 

The  DOD  HCI  Style  Guide  is  based  on  (and  intended  to  supersede)  the  Army,  Navy,  Air  Force, 
and  DODOS  style  guides  cited  in  the  table  above.  The  goal  of  this  effort  is  to  minimize 
unnecessary  user  interface  divers:ty  across  DOD  systems.  There  are  potential  problems  with 
systems  designed  to  accommodate  different  style  guides. 

3.3.4.6.5  Related  standards.  The  following  standards  are  related  to  cultural  convention  services: 

a.  X/Open  Internationalisation  Locale:  L001  (1994):  ja_JP  -  Japanese  for  Japan. 

b.  X/Open  Internationalisation  Locale:  L002  (1994):  da_DK  -  Danish  for  Denmark. 

c.  X/Open  Internationalisation  Locale:  L003  (1994):  de_AT  -  German  for  Austria. 

d.  X/Open  Internationalisation  Locale:  L004  (1994):  en_DK  -  English  for  Denmark. 

e.  X/Open  Internationalisation  Locale:  L005  (1994):  fo_FO  -  Faroese  for  the  Faroes. 

f.  X  'Open  Internationalisation  Locale:  L006  (1994)  is_IS  -  Icelandic  for  Iceland. 

g.  X/Open  Internationalisation  Locale:  L007  (1994)  kl_GL  -  Greenlandic  for 

Greenland. 

h.  X/Open  Internationalisation  Locale:  LOOS  (1994)  lt_LT  -  Lithuanian  for  Lithuania. 

i.  X/Open  Internationalisation  Locale:  L009  (1994):  lv_LV  -  Latvian  for  Latvia. 
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j.  X/Open  Internationalisation  Locale:  L010  (1994):  de_CH  -  German  for 
Switzerland. 

k.  X/Open  Internationalisation  Locale:  LO 1 1  (1 994):  de_DE  -  German  for  Germany. 

L  X/Open  Internationalisation  Locale:  L012  (1994):  en_GB  -  English  for  Great 

Britain. 

m.  X/Open  Internationalisation  Locale:  LOB  (1994):  en_IE  -  English  for  Ireland. 

n.  X/Open  Internationalisation  Locale:  LOB  (1994):  en_US  -  English  for  the  U.S.A. 

o.  X/Open  Intematu  nalisation  Locale:  L015  (1994):  hu_HU  -  Hungarian  for 
Hungary. 

p.  X/Open  Internationalisation  Locale:  L016  (1994):  it_IT  -  Italian  for  Italy. 

q.  X/Open  Internationalisation  Locale:  L017  (1994):  nl_NL  -  Dutch  for  the 

Netherlands. 

r.  X/Open  Internationalisation  Locale:  L018  (1994):  pl_PL  -  Polish  for  Poland. 

s.  X/Open  Internationalisation  Locale:  LOB  (1994):  pt_PT  -  Portuguese  for 

Portugal. 

t.  X/Open  Internationalisation  Locale:  L020  (1994):  ro_RO  -  Romanian  for 
Romania. 

u.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

v.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms. 

w.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

3.3.4.6.6  Recommendations.  Procurements  that  require  software  user  interfaces  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  menu  structures,  command 
languages,  direct  manipulation  dialogs,  forms-based  dialogs,  windowing,  icons,  screen  formatting, 
information  coding,  and  user  guidance. 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative;  parts  10  and  1 1  are  expected  to  be 
informative  on  completion.  Part  3  of  the  ISO  924 1  standard  is  normative;  parts  2-9  and  1 2- 1 7  are 
expected  to  be  normative  on  completion.  Conformance  with  the  overall  ISO  9241  standard  is 
based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 
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Procurements  mast  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  DOD  HCI  Style  Guide  is  recommended  for  customization  to  local  norms. 
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3-J.4.7  Language  bindings  for  GUIs.  These  are  specifications  for  language  bindings  for  the 
display,  manipulation,  and  management  of  objects  in  windows  on  a  raster  graphics  screen. 

3.3.4.7.I  Standards.  Table  3.3-23  presents  standards  for  language  bindings  for  GUIs. 


TABLE  3-3-23  Language  bindings  for  GUIs  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

States 

DoD 

(Lifecycle) 

NPC 

1FFK 

Moduta  Toolkit  Environment  (MTE) 

1295:1993 

Ia/onnadonaJ 

(Approved) 

CPC 

QSF 

Motif  binding  to  C 

Motif  1.2 

InfoimadonaJ 

(Approved) 

CPC 

QSF 

Motif 

Motif  2.0 

InfomutioMj 

(Af^roved) 

3.3.4.7.2  Alternative  specifications.  The  following  specifications  are  also  available  for  support 
of  legacy  systems: 

a.  Rational  Systems  implements  Xlib  with  an  Ada  binding. 

b.  The  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS)  program  has 

an  Ada  binding  for  Xlib  and  Xt  Intrinsics. 

c.  APIW. 

d.  Ada  bindings  for  Motif. 

3 .3.4.7  .3  Standards  deficiencies.  The  X  Window  system  was  designed  with  the  C  language  in 
mind.  Ada  code  can  interface  with  the  X  libraries,  which  are  written  in  C,  but  fundamental 
semantic  incompatibilities  exist  between  the  Ada  and  C  programming  languages. 

No  open-standard  bindings  are  present  from  Ada  to  any  GUI  or  GUI  toolkit,  so  an  Ada 
application  will  have  to  be  written  to  a  GUl'toolkit  using  a  nonstandard  binding  with  portability 
severely  compromised. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  X 1 1 R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version.  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.4.7.4  Portability  caveats.  Although  Ada  compiler  vendors  are  required  by  the  Ada  Language 
Reference  Manual  to  provide  the  capability  for  Ada  to  call  routines  written  in  other  languages, 
they  are  not  required  to  provide  a  capability  that  allows  routines  written  in  other  languages  to  call 
Ada  programs.  The  result  is  reduced  portability,  interoperability,  and  integratability  between  the  X 
Window  system  and  Ada  systems. 
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3  .3.4.7 S  Related  standards.  GUI  standards  and  language  standards  are  related. 

3J.4.7.6  Recommendations.  An  IEEE  study  group  has  begun  work  on  the  specification  of  an 
Ada-93  binding  to  IEEE  1293/Motif.  Several  proprietary  products  are  available  which  supply  an 
Ada-83  binding  to  Motif.  Most  of  these  interface  to  C  function  libraries  (Xlib,  Xt  Intrinsics), 
although  at  least  one  such  product  has  directly  reprogrammed  these  libraries  into  Ada-83.  If  an 
Ada  application  must  be  interfaced  via  an  IEEE  1293  C  binding,  a  layered  approach  should  be 
taken  which  limits  the  direct  calls  of  C  functions  by  the  application.  This  will  allow  a  smoother 
transition  to  a  future  standard  Ada  binding  to  Motif.  Program  managers  for  procurements 
specifying  graphical  windowing  interfaces  should  take  a  practical  and  realistic  approach  in  view  of 
the  current  lack  of  a  standard  for  Ada  bindings  to  GUIs.  Choice  of  an  existing  library  which  takes 
this  layering  approach  is  desirable. 

IEEE  1295  adopts  the  C  language  toolkit  defined  by  the  OSF/Motif  1.2  specification.  Motif  1.2  is 
the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and  programming 
and  data  interfaces. 
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3 .3.4.8  Visualization.  (This  BSA  appear  in  part  3,  User  Interface,  and  part  13,  Human  Factors.) 
Visualization  is  the  method  of  displaying  t  ,ta  in  a  graphical  manner  to  aid  in  recognition  of 
patterns  and  trends  in  data  and  to  give  the  viewer  a.  depiction  of  a  physical  system  that  has  been 
modeled  by  data  points  (e.g„  finite  element  analysis  (FEA)  and  computational  fluid  dynamics 
(CFD)).  Another  technique  is  the  visualization  user  interface  (VUI),  a  GUI  that  interprets  text  and 
numbers  as  pictures  to  show  their  relative  scales  and  other  relationships.  A  VUI  remodels  data  so 
that  text  and  r  ambers  are  hidden  behind  a  picture  expressing  their  complex  relationships. 
Engineering  visualization  is  a  term  freely  applied  o  almost  any  intersection  where  the  engineering 
process  meets  image  creation  technologies. 

..  1  r.8.1  Standards.  Table  3.3-24  presents  standards  for  visualization. 


TABLE  3 .3-24  Visualization  standards 


Standard 

Sponsor 

Standard 

Standard 

Status  | 

Type 

Reference 

(Lifecycle) 

NPC 

ANSI/S  AE 

Aerodynamic  Flow  Visualization  Techniques  and 
Procedure* 

HSJ 1566-  1986 

Informational 

(Approved) 

3J.4.8.2  Alternative  specifications.  There  are  no  alternative  specifications  available,  but 
extensive  academic  research  on  this  topic  is  taking  place,  particularly  in  the  University  of 
Maryland's  Human- computer  Interacts  n  Laboratory  and  the  Software  Psychology  Society. 
Topics  include  using  treemaps  for  visualizing  hierarchical  information,  using  statistical  distortion 
to  promote  the  detection  of  outlying  data,  and  use  of  color  coding  as  a  visualization  aid. 

3.3.4.8 3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3 .3.4.8.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.3.4.8.5  Related  standards.  The  following  standards  are  related  to  visualization  standards: 

a.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  1CBM  Systems 

b.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems 

c.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms 

d.  MIL-HDBK-761 A  (1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems 

e.  DOD-HDBK-763  ( 1 987)  1  luman  Engineering  Procedures  Guide. 

3.3.4.5.6  Recommendations.  There  are  no  recommendations  for  visualization  itself,  but  it  does 
require  the  use  of  power  graphics  generation  if  a  dynamic  system  will  be  shown,  rather  than  a 
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series  of  static  views.  Other  requirements  can  include  a  high  degree  of  mathematical  precision  and 
single-pixel  accuracy  in  rendering. 
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33.4.9  Color  use.  (This  BSA  appears  in  part  3,  User  Interface,  and  part  13,  Human  Factors.) 
The  use  of  color  is  a  vital  part  of  communication  with  the  user  of  computer  applications. 
Computer  representation  of  color  is  done  through  the  use  of  the  Red,  Green,  Blue  (RGB)  color 
separation  method  which  must  be  used  to  approximate  color  definitions  used  in  graphic 
technologies. 

3.3.4.9.1  Standards.  Table  3.3-25  presents  standards  for  color  use. 


TABLE  33-25  Color  use  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8. 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

CIE 

Recommendations  on  Uniform  Color  Spaces,  Color- 
Difference  Equations,  and  Psyehrometric  Color  Terms 

CIE  Pub.  15,Suppl. 

2  (1986) 

Informational 

(Approved) 

IPC 

NATO 

Aircraft  Electronic  Colour  Display  Systems 

STANAG  3940 
(1991) 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 

8:  Requirements  for  displayed  colors 

9241-8 

Informational 

(Draft) 

33.4.9.2  Alternative  specifications.  Alternative  specifications  include  any  user  interface  style 
guide  that  addresses  the  use  and  meaning  of  color. 

33.4.9.3  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards  assumes 
identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons  across 
viewing  environments,  although  developers  are  working  on  models. 

33.4.9.4  Portability  caveats,  't  ranslation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  best.  There  are  three  different  color  definitions 
from  the  CIE.  They  are  CIEXYZ,  C1ELAB,  and  CIELUV.  These  standards  have  existed  for  a 
long  time  and  are  seen  as  the  common  basis  for  any  future  unifying  definitions. 

One  problem  with  the  use  of  color  is  color  blindness.  To  accommodate  the  color  blind,  if  color  is 
used  to  convey  important  information,  then  a  second  method  should  also  be  used  (such  as 
brightness  of  the  color). 

33.4.9.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
the  use  of  color: 

a.  MIL-STD- 1794  (1986)  Human  Factors  Engineering  Program  for  1CBM  Systems 

b.  MIL-STD- 1 800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems 
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c.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms 

d.  MEL-HDBK-761 A  (1989)  Human  Engineering  Guidelines  for  Management  Info. 
Systems 

e.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

3 J3.4.9.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  The  DOD  HCI  Style  Guide  is  recommended,  particularly  section  4.3  which 
addresses  the  use  and  meaning  of  color. 
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3 3S  Window  management.  Window  management  specifications  define  how  windows  are 
created,  moved,  stored,  retrieved,  remo-  ed,  and  related  to  each  other. 

3 .3.5.1  Independent  window  manage  \  :nt  services.  (This  BSA  appears  both  in  part  3  and  part 
9.)  Window  management  services  are  a  necessary  part  of  any  windows  system  to  perform 
functions  such  as  resizing  or  moving  windows.  These  services  are  not  to  be  confused  with 
services  managing  individual  windows  as  though  they  were  separate  terminals. 

3.3.5.1.1  Standards.  Table  3.3-26  presents  standards  for  independent  window  management 
services. 


TABLE  3.3-26  Independent  window  management  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

IEEE 

Modular  toolkit  Environment  (MTE) 

1295:1993 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

MIT  X 
Consortium 

X  Window  oyttem  (Tab  Window  Manger) 

X11R5 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

3 .3.5. 1.2  Alternative  specifications.  The  following  specifications  are  also  available  for  legacy 
support: 

a.  APIW 

b.  USL/Sun  Open  Look  Windows  Manager  (olwm) 

c.  IBM  SA/  Presentation  Manager  Window  Manager. 

3.3.5.1.3  Standards  deficiencies.  Although  all  window  managers  perform  functions  such  as 
window  resizing  and  moving  (window  .•'nipulation),  some  do  not  manage  their  windows 
independently,  as  if  rach  window  wei  '  larate  system.  Failure  to  manage  windows 
independently  may  create  situations  in  a  an  application  seizing  in  one  window  may  propagate 
the  errors  to  other  windows  causing  the  a  seize  (lock  up).  In  addition,  without  an  independent 
window  manager,  usually  it  is  not  possible  to  invoke  programs  that  run  in  graphical  mode  at  the 
same  time  (but  in  different  windows  on  the  same  screen)  as  programs  running  in  character  mode. 
Certain  windows  systems  running  under  single-tasking  DOS  also  do  not  support  independent 
window  managers. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version.  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
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threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.5. 1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.3.5.1.5  Related  standards.  No  standards  are  related  to  independent  window  management 
standards. 

3 .3.5.1.$  Recommendations.  A  procurement  should  specify  a  Windows  Manager  that 
accommodates  window  manipulation  and  application  seizure  protection.  Windows  systems  using 
X  Windows  operating  on  protected  operating  systems  like  UNIX  are  mote  robust  (i.e.,  the  failure 
of  one  application  will  not  cause  other  applications  to  fail  automatically)  than  some  running  on  the 
unprotected  DOS  operating  system. 
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3.3.5. 2  Multiple  displays.  Multiple  display  services  allow  the  use  of  multiple,  possibly 
heterogeneous,  displays  as  separate  windows  within  an  application. 

3.3.5. 2.1  Standards.  Table  3.3-27  presents  standards  for  multiple  displays. 


TABLE  3.3-27  Multiple  displays  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Motif 

Motif  1.2 

Adopted 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

33.5 3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary  and 
should  only  be  used  to  support  legacy  systems. 

33.5.23  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version.  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  avaiable  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

33.5.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.3.5.23  Related  standards.  No  standards  are  related  to  multiple  display  standards. 

33.5.2.6  Recommendations.  Motif  1 .2  is  the  current  version  of  the  OSF  specification  for  GUI 
behavior  and  appearance  and  programming  and  data  interfaces.  Motif  1 .2  includes  specifications 
for  multiple  physical  displays  used  in  the  same  logical  display  without  downgrading  the 
performance  of  the  most  advanced  display  to  that  of  the  least  advanced. 
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3  J £ 3  Shared  screens.  Shared  screen  capabilities  enable  two  or  more  workstations  to  display 
the  same  screen  simultaneously.  Changes  made  by  one  user  can  be  seen  by  others  as  they  are 
made.  Shared  screens  can  be  implemented  in  two  ways.  One  way  enables  people  to  view  each 
other's  screen,  while  one  person  makes  changes.  The  other  way  enables  people  to  run  the  same 
application  on  both  screens  so  both  users  can  make  changes  simultaneously. 

3. 3.5. 3.1  Standards.  Table  3.3-28  presents  standards  for  shared  screens. 


TABLE  3.3-28  Shared  screens  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.3.5.3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3  J.5.3.3  Standards  deficiencies.  There  are  no  standards  to  have  deficiencies. 

3  J.5.3.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3_3.5.3.5  Related  standards.  Currently,  no  standard  specifies  sharing  and  updating  by  two  or 
more  users  on  the  same  screen(s),  and  none  are  anticipated. 

3J.5.3.6  Recommendations.  No  standards-based  way  to  require  that  screens  be  sharable  and 
updatable  by  two  or  more  communicating  users  working  on  the  same  screen(s)  is  available  for  a 
procurement,  and  no  standards  are  anticipated. 


April  7,  1997 


3.3-64 


Version  3.1 


Information  Technology  Standards  Guidance 


1  Isnr  Interface  Services 


3.3.5.4  On-line  help.  On-line  help  allows  the  user  to  access  application  reference  material 
directly  from  the  application  or  system  through  the  computer. 

3.3.S.4.1  Standards.  Table  3.3-29  presents  standards  for  on-line  help. 


TABLE  33-29  On-line  help  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8. 
Vernon  3.0:  1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(ARwoved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

NPC 

IPRP. 

Recommended  Practice  for  Graphical  liter  Interface 
Drivability 

P1201.2 

Informational 
(Draft  (Project 
being  canceled,  lack 
of  progrea*)) 

3 .3. 5.4. 2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.3.5.4.3  Standards  deficiencies.  On-line  help  is  included  in  the  P1201.2  Drivability 
specification.  However,  this  document  is  a  "Recommended  Practice"  rather  than  an  IEEE 
standard. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  X 1 1 R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1 .2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  are  resolved. 

3.3.5.4.4  Portability  caveats.  There  are  no  known  portability  problems  with  the  existing 
standards. 

3.3.5.4.5  Related  standards.  No  standards  are  related  to  on-line  help  standards. 

3.3.5.4.6  Recommendations.  The  only  specification  for  on-line  help  available  for  a  procurement 
is  the  specification  provided  by  the  proprietary  GUIs.  The  P1201.2  effort  is  not  yet  available.  The 
DOD  HCI  Style  Guide,  TAFIM,  Volume  8,  is  recommended  for  its  partial  specification. 
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3J.5.5  D livability.  Drivability  refers  to  the  ease  with  which  users  may  transfer  from  one  GUI 
"look  and  feel"  or  application  to  another  with  minimal  interference,  errors,  confusion,  relearning, 
or  retraining.  The  intent  is  to  eliminate  error  provoking  inconsistencies,  misleading  expectations 
about  the  results  of  user  actions,  gross  inconsistencies  in  the  high-level  user  model  or  metaphor, 
and  incompatible  motor  control  tendencies.  This  only  relates  to  those  aspects  for  which 
consistency  is  necessary  to  promote  easy  transfer  among  conforming  environments. 

3. 3.5. 5.1  Standards.  Table  3.3-30  presents  standards  for  drivability. 


TABLE  33-30  Drivability  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8. 
Venion  3.0: 1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif  Stylo  Guide 

Motif  SG  Rev. 
1.2:1992 

Mandated 

(Approved) 

CPC 

QSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  10 

Informational 

(Approved) 

NPC 

IKHR 

Recommended  Practice  for  Graphical  User  interface 
Drivability 

PI  201 .2 

Informational 
(Draft  (Project 
being  canceled,  lack 
ofproRteti)) 

3.3.5.5.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  AP1W  drivability 

b.  IBM:  SAA's  Common  User  Access  (CUA). 

3.3.5.5.3  Standards  deficiencies.  Motif  2.0  is  somewhat  incompatible  with  the  multi-threading 
implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version.  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
XI 1R6  is  resolved. 

3.3.5.5.4  Portability  caveats.  The  IEEE  PI 20 1.2  Working  Group,  is  producing  a 
"Recommended  Practice"  rather  than  a  mandatory  standard.  This  specification  uses  the  best 
features  from  commercial  products,  as  well  as  features  from  various  ISO  standards  and  hui  in- 
computer  interface  research.  Its  hybridization  prevents  it  from  being  completely  compatible  with 
any  particular  commercial  product.  Portability  problems  can  result  if  vendors  selectively 
implement  parts  of  P 1 20 1 .2. 
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3J.5.5.5  Related  standards.  The  following  standards  are  related  to  drivability  or  drivability 
standards: 

a.  ISO  DIS  9995  Parts  1-7:  Keyboard  Layouts. 

b.  ISO  TC159/SC4/WG5:  This  software  Ergonomics  and  Man-Machine  Dialog 
committee  is  developing  parts  of  ISO  9241  ("Ergonomics  of  Visual  Display 
Terminals"). 

c.  ANSI  X3 V 1 .9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
VMUIF. 

d.  ISO/IEC  JTC  1/SC18/WG9:  Working  on  a  VMUDF.  (This  effort  moves  the  ANSI 
work  of  X3V1.9  to  ISO  status.)  The  group  also  is  developing  standards  for  user 
interfaces  and  symbols  associated  with  text  and  office  systems. 

e.  ANSI  HFS-HCI:  TTtis  ANSI  committee  is  working  on  drafts  on  the  design  process, 
information  presentation,  forms-based  dialog,  and  window-based  interaction. 

3.3.5 .5.6  Recommendations.  The  mandated  standards  are  recommended.  IEEE  PI 20 1.2 
specifies  recommended  practice  for  drivability  of  GUI  based  applications.  IEEE  P1201.2  will  be 
recommended  for  use  once  completi-'. 
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3  J  .5.6  Commands,  menus,  and  dialog  services.  In  any  software  system  it  is  necessary  for 
users  to  command  it  to  perform  functions.  In  a  GUI  commands  are  entered  either  by  pointing  and 
clicking  on  a  menu  item,  or  by  entering  commands  interactively  in  data  entry  windows  known  as 
dialogs.  Dialog  support  services  translate  the  data  entered  for  display  to  that  which  is  actually 
displayed  on  the  screen  (e.g.,  cursor  movements,  keyboard  data  entry,  external  data  entry 
devices). 

3. 3.5. 6.1  Standards.  Table  3.3-31  presents  standards  for  command,  menu,  and  dialog  services. 


TABLE  3.3-31  Commands,  menus,  and  dialog  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

DOD 

Human -Computer  Interfacr  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  10 

Informational 

(Approved) 

[PC 

ISO 

Software  Ergonomics  and  M-n- Machine  Dialogue 

TC159/5C4/WG5 

Informational 

(Draft) 

3  J.5.6.2  Alternative  specifications.  The  following  proprietary  specifications  are  available  for 
support  of  legacy  systems: 

a.  IBM:  SAA  Presentation  Manager 

b.  Microsoft:  MS  Windows. 

3.3.5.6.3  Standards  deficiencies.  The  emerging  ISO  standard  on  Software  Ergonomics  and 
Man-Machine  Dialogue  (under  development  in  ISO  TC159/SC4/WG5)  contains  only  text-based 
style  information  rather  than  implementable  specifications. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  is  available  and  until  potential  conflicts  between  Motif  2.0  and 
X11R6  is  resolved. 

3.3.5.6.4  Portability  caveats.  Because  the  ISO  effort  only  addresses  style,  products  written  to 
the  ISO  standard  may  not  be  portable. 

3.3.5.6.5  Related  standards.  The  following  standards  are  related  to  dialog,  command,  and  menu 
service  standards: 
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a.  ISO  TC159/SC4/WG5:  This  software  Ergonomics  and  Man-Machine  Dialog 
committee  is  developing  parts  of  ISO  9241  ("Ergonomics  of  Visual  Display 
Terminals"). 

b.  ISO  1 1730  Forms  Interface  Management  System  (FIMS). 

c.  ANSI  HFS-HCI:  This  ANSI  committee  is  working  on  the  design  process, 
information  presentation,  forms-based  dialogs,  and  window-based  interaction. 

33.5.6.6  Recommendations.  No  strong  recommendadon  can  be  made.  For  specifying  how  to 
enter  commands  in  graphical  menus  through  dialogs,  only  proprietary  offerings  are  available  for 
procurement.  The  ISO  effort  is  in  its  early  stages  and,  even  when  it  is  complete,  it  will  not  offer 
implementable  specifications  but,  rather,  style  information. 

The  Human-Computer  Interface  (HCI)  Style  Guide  is  recomomended.  This  style  guide  provides  a 
common  framework  for  HCI  design  and  implementation  with  emphasis  on  standard  look  and  feel 
for  GUI  based  applications. 
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3  J .5.7  Input  device  management  and  control.  Input  device  management  covets  the  keyboard, 
pointing  devices,  tablets,  and  touch  screens  which  allow  the  user  to  control  the  application. 

3. 3.5. 7.1  Standards.  Table  3.3-32  presents  standards  for  input  device  management  and  control. 


TABLE  3.3-32  Input  device  management  and  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

LnfoimatkxuJ 

(N.A.) 

3J.5.7.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

333.73  Standards  deficiencies.  Such  input  devices  as  pointing  devices,  tablets,  and  touch 
screens  have  no  input  device  service  standards,  and  none  are  known  to  be  developing. 

3  J.5.7.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

333.73  Related  standards.  The  following  standards  are  related  to  input  device  management 
and  control: 

a.  ISO  DIS  9995  Parts  1-7:  Keyboard  Layouts. 

b.  ANSI  X3V!  .9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
VMUIF. 

c.  ISO/1EC  JTC  1/SC18/WG9:  Working  on  a  VMUIF.  (This  effort  moves  the  ANSI 
work  of  X3V 1 .9  to  ISO  status. ) 

3.3.S.7.6  Recommendations.  There  are  no  recommendations. 
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3 .3.5.8  Multimedir  input  APIs  to  windows-based  systems.  Multimedia  input  refers  to  the 
integration  of  windows  systems  with  non-traditional  computer  input,  such  as  audio  (digital  and 
voice)  and  video  (photographic  and  full  motion). 

3.3.5.8.1  Standards.  Table  3.3  -33  presents  standards  for  multimedia  input  APIs  to  windows- 
based  systems. 


TABLE  3.3-33  Multimedia  in,  *  APIs  to  windows-based  systems  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

lnfoan*tion*i 

(N.A.) 

3.3.5.8.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3 .3.5.8 .3  Standards  deficiencies.  There  are  no  multimedia  API  standards  for  windows-based 
systems,  and  none  are  known  to  be  under  development. 

3.3.5.8.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.3.5.8.5  Related  standards.  The  following  standards  are  related  to  multimedia  input  APIs  or 
their  standards: 


a.  ANSI  X3V1.9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
VMUIF. 

b.  ISO/IEC  JTC  1/SC18/WG9:  Working  on  a  VMUIF.  (This  effort  moves  the  ANSI 
work  of  X3V1.9  to  ISO  status.) 

3.3.5.8.6  Recommendations.  There  are  no  standards  to  recommend. 
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33.6  Character-based  user  interface.  Character-based  user  interface  can  be  either  i  command- 
line  interface  or  a  menu-driven  interface  similar  to  a  graphical  user  interface,  but  it  does  not  use 
graphics  and  may  depend  solely  on  the  keyboard  for  user  input,  i.e.,  not  make  use  of  an  explicit 
pointing  device.  Modem  systems  and  applications  are  and  will  be  based  upon  graphical  user 
interfaces  and  the  associated  standards  for  such  systems.  However,  many  legacy  systems  still 
include  a  large  number  of  character-based  terminals.  The  following  sections  discuss  standards 
which  can  be  applied  to  such  systems.  No  recommendations  will  be  made  as  to  the  use  of  these 
standards  on  legacy  systems,  since  such  recommendations  may  be  inappropriately  or 
uneconomically  applied  to  such  systems. 


3.3.6.1  Style  guide.  A  style  guide,  which  is  part  of  the  Presentation  Management  layer  in  the 
NIST  User  Interface  Reference  Model,  determines  the  "look"  of  an  interface.  Many  style  guides 
for  GUIs  have  application  to  character-based  interfaces. 

3.3.6.1.1  Standards.  Table  3.3-34  presents  style  guides. 


TABLE  3.3-34  Style  guide  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Facton 
Engineering  of  Visual  Display  Terminal  Woriutations 

100-1988 

Informational 

(Approved) 

IPC 

NATO 

Principles  of  Presentation  of  Information  in  Aircrew 
Stations 

STANAG  3705 

informational 

(Approved) 

GPC 

DOD 

UscrAlomputer  Interface 

MIL-STD-1801  29 
May  1987 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Performance  Requirements  for 
Systems 

M1L-STD-1800A 

10  Oct.  1990 

Informational 

(Approved) 

GPC 

DOD 

DOD  Handbook,  Human  Engineering  Guidelines  for 
Management  Information  Systems 

MEL-HDBK-76IA 
30  Sep.  1989 

Informational 

(Approved) 

GPC 

DOD 

Guidelines  for  Designing  User  Interface  Software 

ESD-TR-86-278 

Informational  [ 

(Approved)  | 

GPC 

DOD 

Department  of  Defense  Intelligence  Information  Systems 
Style  Guide 

DODIIS  Style 

Guide.  10/91 

Informational  j 
(Approve^) 

GPC 

DOD 

Air  Force  Intelligence  Data  Handling  System  (1DHS)  Style 
Guide 

mam 

Informational  j 
(Approved)  J 

GPC 

DOD 

Human  Factors  Guidelines  for  the  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier-Machine 
Interface 

ATCCS  Guidelines 
v.  1.0  and  v.2.0. 
1990  and  1992 

Informational  | 
(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS,  Version 
1.1.  1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

M1L-STD-1472D 
Notice  2.  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Guidelines  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

GPC 

DOD 

Human  Engineering  Requirements  for  Military  Systems. 
Equipment,  and  Eaalines 

MIL-STD-46855B 
26  May  1994 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Ergonomic  Requirement  for  Office  Work  with  VDTs  Put 
10:  Dialogue  principled 

924M0:I996 

Informational 

(Approved) 

IPC 

ISO 

9241-11 

Informational 

(Drift) 

IPC 

ISO 

9241-12 

Informational 

(Drift) 

IPC 

ISO 

Ergonomic  Requirement  for  Office  Work  with  VDT*  Put 
13:  liter  guidance 

9241-13 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  Requirement  for  Office  Work  with  VDT*  Put 
l  •:  Menu  dialogs 

9241-14 

Informational 

(Draft) 

IPC 

ISO 

raansQ 

9241-15 

Informational 

(Draft) 

IPC 

ISO 

isos 

9241-16 

Informational 

(Draft) 

IPC 

ISO 

Ergonomic  RequireowUt  for  Office  Work  with  VDT*  Put 
17:  Form- filling  dialog* 

9241-17 

Informational 

(Draft) 

IPC 

ISO/IEC 

Graphical  Symbol*  Used  on  Screens:  Interactive  Icons 

11581 

Informational 
(Draft  (CD)) 

NPC 

mpp 

Recommended  Practice  for  Graphical  User  Interface 
Drivability 

P1201.2 

Informational 
(Draft  (Project 
being  canceled,  lack 
of  progress)) 

GPC 

DOD 

Joint  Satellite  Control  (JSC)  Human  Computer  Interface 
Standard,  Version  1.0 

JSC  HO  Sid.,  1.0 

Informational 

(Draft) 

3.3.6.1.2  Alternative  specifications.  Several  applicable  consort  or  de  facto  style  guides  are 
available  for  software  user  interfaces.  These  style  guides  promote  consistency  in  user  interface 
design  across  applications.  However,  conformance  with  one  or  more  of  the  style  guides  listed 
below  does  not  guarantee  conformance  with  ergonomic  standards  (e.g.,  ISO  9241 ).  These  style 
guides  include  the  following: 

a.  Defense  Intelligence  Agency  (DLA)  Standard  User  Interface  Style  Guide  for 
Compartmented  Mode  Workstations. 

b.  DDS-2600-62 15-91:  Compartmented  Mode  Workstation  Labeling:  Source  Code 
and  User  Interface  Guidelines. 

d.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft). 

e.  Object-Oriented  Interface  Design:  IBM  common  user  Access  Guidelines  (IBM). 

f.  Macintosh  Human  Interface  Guidelines  (Apple  Computer). 

g.  SAA  Presentation  Manager  Style  Guide/Common  User  Access  (CUA)  (IBM). 
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h.  Air  Force  Standard  Systems  Center  GUI  Style  Guide,  SSCR  700-010,  Vol.  I. 

L  User  Interface  Specifications  for  the  Global  command  and  Control  System 
(GCCS),  version  1.0,  draft,  October  1994. 

j.  Theater  Battle  Management  Style  Guide  (U.S.  Navy). 

k.  Army  Theater  Battle  Management  HCI  Specification. 

L  Navy  JMCIS. 

3.3.6.13  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

33.6.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

33.6.13  Related  standards.  The  following  standards  are  related  to  user  interface  style  guides: 

a.  DOD  Human-Computer  Interface  (HCI)Style  Guide,  TAFIM  Volume  8,  Version 
2.0, 30  September  1994.  The  Human-Computer  Interface  (HCI)  Style  Guide 
provides  a  common  framework  for  HCI  design  and  implementation  with  emphasis 
on  standard  look  and  feel  for  GUI  based  applications. 

b.  OSF  Motif  Style  Guide,  Motif  SG  Rev.  1 .2: 1 992. 

c.  ISO  924 1-1:1 992,  Ergonomic  requirements  for  office  content  and  usage  of  the 
multipart  ISO  9241  standard.  A  revised  version  of  ISO  9241-1  is  currently  at  the 
CD  level  and  will  soon  be  released  for  D1S  ballot.  (Parts  1  and  2  of  the  ISO  9241 
standard  are  informative:  parts  10  and  1 1  are  expected  to  be  informative  on 
completion.  Parts  12-17  are  expected  to  be  normative  on  completion. 

Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all 
normative  parts  that  apply  to  a  particular  product.) 

d.  ISO  9241-2:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  presents  an  overview  of  factors  that  should  be  considered 
when  designing  tasks  to  be  performed  in  a  specific  computing  environment. 

e.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  -  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

f.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terms. 

g.  NIST  FIPS  158-1,  User  Interface  Component  of  the  Applications  Portability 
Profile. 
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h.  MIL-STD- 1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

L  MIL-HDBK.-759B(2)(  1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

j.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

k.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

L  ITU-T  E.  1 34  Human  Factors  Aspects  of  Public  Terminals:  Generic  Opening 
Procedures. 

m.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.3.6.1.6  Recommendations.  No  recommendation  is  made  for  legacy  systems  which  are  based 
upon  a  character-based  interface.  Modifications  of  software  running  on  such  systems  should  be 
consistent  with  the  existing  look  and  feel  of  the  system.  New  systems  should  be  based  on 
equipment  which  supports  GUI  applications. 
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33.62  Character-based  terminal  support  These  specifications  provide  the  ability  to  mimic  a 
GUI  interface  on  a  character-based  terminal. 

3. 3.6. 2.1  Standards.  Table  3.3-35  presents  standards  for  character-based  terminal  support. 


TABLE  3.3-35  Character- based  terminal  support  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

DU 

AJpteWmdowt 

AlphaWindow* 

Information*! 

(Approved) 

3 3.6 2.2  Alternative  specifications.  The  following  specifications  are  also  available  to  support 
legacy  systems: 

a.  USL's  SVID,  which  provides  screen/menu  enhancements  to  Curses,  which  will  be 
compatible  with  Open  Look. 

b.  Some  proprietary  implementations  of  Motif  and  MS  Windows  on  character-based 
terminals. 

3J.6.2.3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3 3.6.2A  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3 .3.6.2 S  Related  standards.  Some  virtual  APIs  can  provide  character  terminal  support 

33.6.2.6  Recommendations.  No  recommendation  is  made  for  legacy  system  which  are  based 
upon  a  character-based  interface. 

AlphaWindows  specifies  a  standard  developed  by  the  Display  Industry  Association  for  displaying 
applications  software  on  low-cost  terminals  which  do  not  support  graphics. 
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3J.6.3  Electronic  forms.  (This  BSA  appears  in  part  3,  User  Interface,  part  4,  Data 
Management,  and  part  S,  Data  Interchange.)  These  standards  specify  the  functional  interface 
requirements,  transfer  of  various  fields  and  the  interface  between  programming  languages  and 
form  filling  applications  for  use  on  a  terminal  display. 

3.3.6.3.1  Standards.  Table  3.3-36  presents  standards  for  electronic  forms. 


TABLE  3.3-36  Electronic  forms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Kim 

GPC 

DOD 

DOD  Standardized  Electronic  Form*  Requirement* 

JffiO-E-2300 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Forms  Interface  Management  System  (RMS) 

11730:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Open  System  Interconnection  Profile  (GOSIP 
2);  Virtual  Terminal  Form*  Clat*  Profile 

IH 

Informational 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Utilitie*,  Issue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  Unix  Specification:  X/Open  Curies,  Issue  4  (part  of 

XP04) 

C437  (2/95) 

Emerging 

(Approved) 

GPC 

DOD 

DOD  Forms  Management  Program  Procedures  Manual 

DOD  77 50.7- M 

Informational 

(Approved) 

CPN-C 

Numerous 

vendor* 

Query  by  Forms 

Query  by  Forms 

Informational 

(Approved) 

IPC 

iso/mc 

OSI  Virtual  Terminal  Basic  Clast  Service,  Amendment  2: 
Additional  Functional  Units  (forms  capability) 

9040:1990  DAM  2 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Virtual  Terminal  (VT)  Basic  Class  Protocol,  Part  1, 
Amendment  2:  Additional  Functional  Units  (Forms 
Capability) 

9041-1:1990  DAM 

2 

Informational 

(Draft) 

CPC 

X/Open 

Internationalized  Terminal  Interfaces  (XCURSES),  Issue  4 

S422  (4/94) 

Informational  1 
(Superseded) 

3.3.6.3.2  Alternative  specifications.  The  Berkeley  Software  Distribution  (BSD)  4.2/4.3  UUN1X 
Curses  are  also  available. 

3.3.6.3.3  Standards  deficiencies.  The  X/Open  Portability  Guide  4  (XPG4)  Curses  is  based  on 
the  System  V  Interface  Definition  (SVID)  Issue  2  Curses  version,  which  does  not  include  the 
SVID's  forms  and  menu  libraries. 

Forms  Class  Virtual  Terminal  has  bindings  in  C  only. 

DOD  has  developed  a  specification  for  electronic  forms  (JIEO-E-2300).  It  defines  the  minimum 
operational  requirements  for  electronic  forms  software  and  mandates  an  interchange  file  format 
based  on  Forms  Interface  Management  System  (RMS). 
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3J.6J.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3J.6.3.5  Related  standards.  The  Forms  Class  Virtual  Terminal  requires  the  Synchronous  mode 
(S-mode)  of  operation  and  specifies  simple  delivery  control.  The  following  standards  are  related 
to  forms  query  and  management: 

a.  ISO  9075:  SQL 

b.  ANSI  X3. 135-1992:  SQL2 

c.  NIST  FIPS  127-2:  SQL 

d.  NIST  FIPS  193:  SQL  Environments 

3  J.6.3.6  Recommendations.  The  recommended  standard  is  JIEO-E-2300.  For  User  Interface, 
FIMS  should  be  considered.  For  Data  Management,  make  sure  the  forms  management  systems 
are  compatible  with  FIPS  127-2  SQL.  Database  forms  management  systems  should  be  integrated 
with  the  SQL  database  language  and  formats  set  forth  in  FIPS  PUB  127-2. 
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3.3.7  Audio  user  interface.  An  audio  user  interface  allows  voice  commands  as  input  or  voice  or 
digital  sound  output 

3.3.7.1  Voice  recognition.  Voice  recognition  is  the  conversion  of  spoken  words  into  computer 
text  Speech  is  digitized  first  then  matched  against  a  dictionary  of  coded  wave  forms.  The  matches 
are  converted  into  text  as  if  the  words  were  typed  on  the  keyboard.  Speaker-dependent  systems 
must  be  trained  before  using  by  taking  samples  of  actual  words  from  the  person  who  will  use  it 
Speaker-independent  systems  can  recognize  limited  vocabularies  such  as  numeric  digits  and  a 
handful  of  words. 

3.3.7.1.1  Standards.  Table  3.3-37  presents  standards  for  voice  recognition. 


TABLE  3.3-37  Voice  recognition  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Informed  on*J 

(N.A.) 

3 J.7.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3J.7.1J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.3.7. 1.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.3.7. 1.5  Related  standards.  The  following  standards  are  related  to  voice  recognition  or  voice 
recognition  standards: 

a.  ANSI  X3V1.9  User-System  Interfaces  and  Symbols  committee:  Working  on  a 
VMUIF. 

b.  ISO/EEC  JTC  1/SC  1 8/WG9:  Working  on  a  VMUIF.  (This  effort  moves  the  ANSI 
work  of  X3V1.9  to  ISO  status.) 

3.3.7.1.6  Recommendations.  There  are  no  standards  to  recommend. 
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3 .3.7.2  Speech  synthesis.  Speech  synthesis  is  the  generation  of  machine  voice  by  arranging 
phonemes  (e.g.,  k,  ch,  and  sh)  into  words.  Speech  synthesis  performs  real  time  conversion 
without  a  predefined  vocabulary  but  does  not  create  human-sounding  speech. 

3.3.7.2.1  Standards.  Table  3.3-38  presents  standards  for  speech  synthesis. 


TABLE  3-3-38  Speech  synthesis  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Infonnitional 

(N.A.) 

33.7.2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

33.7.23  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.3.7.2.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3 3.7.23  Related  standards.  The  following  standards  are  related  to  speech  synthesis  or  speech 
synthesis  standards: 

a.  X3V1.9  User-System  Interfaces  and  Symbols  committee:  Working  on  a  VMU1F. 

b.  ISO/IEC  JTC  1/SC18/WG9:  Working  on  a  VMUIF.  (This  effort  moves  the  ANSI 
work  of  X3V1.9  to  ISO  status.) 

3.3.7.2.6  Recommendations.  There  are  no  standards  to  recommend. 
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3J.7.3  Voice  messaging.  Voice  messaging  is  the  use  of  voice  mail  as  an  alternative  to  electronic 
mail,  in  which  voice  messages  are  recorded  intentionally,  not  because  the  recipient  was  not 
available.  Voice  mail  is  a  computerized  telephone  answering  system  that  digitizes  incoming  voice 
messages  and  stores  them  on  disks.  It  usually  provides  auto  attendant  capability,  which  uses 
prerecorded  messages  to  route  the  caller  to  the  appropriate  person,  department,  or  mail  box. 

3.3.7.3.1  Standards.  Table  3.3-39  presents  standards  for  voice  messaging. 


TABLE  3.3-39  Voice  messaging  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/ffiC 

Us tt  Interface  to  Telephone- Baaed  Services  -  Voice 
Messaging  Applications 

13714:1995 

Informations) 

(Approved) 

IPC 

ISO/IEC 

Voice  Messaging  User  interface  Fomin  (VMUIF)  (related 
to  ANSI  X3V  1.9) 

JTC1/SC18/WG9 

Informational 

(Formative) 

3.3.7.3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3J.7.3  J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown. 

3  J.7.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specification  are 
unknown. 

3J.7.3.5  Related  standards.  No  standards  are  related  to  voice  messaging  standards. 
3.3.7.3.6  Recommendations.  There  are  no  recommendations. 
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33.8  Security.  Security  concerns  for  user  interface  services  concentrate  on  identifying  and 
authenticating  the  access  control  restrictions  placed  on  system  users,  as  well  as  the  labeling  of 
data  by  which  those  access  control  decisions  can  be  made. 

33.8.1  User  interface  security  labeling.  (This  BSA  appears  in  part  3  and  part  10.)  User 
interface  security  labeling  provides  a  human  readable  representation  of  the  internal  security  labels 
associated  with  data  management,  data  interchange,  graphics,  data  communications,  system,  and 
distributed  computing  services. 

33.8.1.1  Standards.  Table  3.3-40  presents  standards  for  user  interface  security  labeling. 


TABLE  3340  User  interface  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

mmm 

Mandated 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Adopted 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-6216- 

91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  Uier  Interface 
Guideline*,  Revision  1 

DDS-2600-6243- 

91 

informational 

(Approved) 

GPC 

DOD 

Defeme  Intelligence  Agency  Standard  User  Interface  Style 
Guide  for  Compartmented  Mode  Workstations 

DIA  Style  Guide: 
1983 

Informational 

(Approved) 

33.8.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

33.8.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

33.8.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

33.8.1.5  Related  standards.  DOD  5200.28-STD  is  a  related  standard.  DOD  5200. 1-R, 
"Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy  for  security 
classification,  declassification,  and  marking  of  DOD  information.  It  also  contains  DOD  policy  for 
safeguarding  of  classified  information,  including  accountability,  storage,  transmission,  and 
destruction  of  the  information. 

Security-related  interface  requirements  for  workstations  operating  in  System  High  or 
Compartmented  Mode  are  discussed  in  DDS-2600-6243-91  and  the  D1A  Style  Guide,  which 
provide  the  basis  for  the  security  portion  of  the  HCI  Style  Guide  (TAFIM  Volume  8). 

33.8.1.6  Recummendations.  Appendix  A  of  the  TAFIM,  Volume  8,  DOD  HCI  Style  Guide, 
outlines  security  presentation  guidelines  for  workstations  and  is  recommended. 
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3J.8.2  Personal  authentication.  (This  BSA  appears  n  part  2,  part  3,  part  9,  and  part  10.) 
Personal  authentication  supports  the  accountability  objective  of  being  able  to  trace  all  security 
relevant  events  to  individual  users.  In  addition  to  supporting  unique  identification,  standards  are 
provided  to  authenticate  the  claimed  identity. 

3.3.8.2.1  Standards.  Table  3.3-41  presents  standards  for  personal  authentication. 


TABLE  33-41  Personal  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

DCE  1,1  Security 
Service*:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Phi* word  Uuge 

FIPS  PUB  112: 
1985 

Mandated 

(Approved) 

CPC 

OSF 

Diitributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Ajproved) 

GPC 

NIST 

Guide] in  i  on  Evaluation  of  Technique*  for  Automated 
Persona]  Identification 

FIPS  PUB  48:1977 

Informational 

(Approved) 

[PC 

1SO/1EC 

Information  Technology  -  Open  Syilemi  Interconnection  - 
The  Directory ;  Authentication  Framework  edition  2  (Same 
aa  ITU-T  X.509: 1993) 

9594-8.2:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Uie  of  Advanced  Authentication  Technology 
Alternative* 

FIPS  PUB 
190:1994 

Informational 

(Approved) 

CPC 

IETF 

A  One- lime  Paiiword  Syttem 

RFC  1938: 1996 

Emerging 

(Draft) 

LPC 

CCBB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1.0 

CC  Venion  1.0: 
1996 

Emerging 

(Draft) 

CPC 

IETF 

The  Kerberos  Network  Authentication  Service  (V5) 

RFC  1510:1993 

Informational 

(Draft) 

3.3.8.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.3.8.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.3.5.2.4  Portability  caveats.  OSF  DCE  Version  l.l's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  lor  Kerberos  Version  5. 

3.3.8.2.5  Related  standards.  The  following  standards  are  related  to  personal  authentication 
standards  (particularly  TCSEC): 

a.  DOD  5200.28-STD,  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

b.  NCSC-TG-017,  Version  1,  "A  Guide  to  Understanding  Identification  and 
Authentication  in  Trusted  Systems 


April  7,  1997 


3.3-83 


Version  3. 1 


Information  Technology  Standards  (lindane* 


User  Interface  Services 


c.  CSC-STD-002-85,  "Password  Management  Guideline" 

d.  NCSC-WA-002-85,  "Personal  Computer  Security  Considerations" 

e.  ITU-T  X.509  (1993)  (same  as  ISO  9594-8),  The  Directory:  Authentication 
Framework 

3 -3. 8.2.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.4  Data  management  services.  Data  management  service  standards  provide  (1)  data 
dictionary/directory  services  for  accessing  and  modifying  data  about  data  (i.e.,  metadata),  (2)  the 
database  management  services  for  accessing  and  modifying  structured  data,  and  (3)  the  distributed 
data  service  for  accessing  and  modifying  data  from  a  remote  database. 

NOTE:  Th'oughout  Part  4,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  I  PC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Consortia  Private  Non-Consensus  =  CPN-C 

f.  National  Public  Non-Consensus  =  NPN-C 

3.4.1  Data  management  system.  These  standards  provide  the  basic  database  services  needed  by 
an  application  using  a  database.  A  Database  Management  System  (DBMS)  is  an  application  used 
to  create,  store,  retrieve,  change,  manipulate,  sort,  format,  and  print  the  information  in  a  database. 

3.4.1.1  Basic  database  services.  Basic  database  services  include  data  definition,  manipulation, 
query,  and  integrity,  embedded  Structured  Query  Language  (SQL),  and  dynamic  facilities.  Data 
definition  includes  create,  alter,  and  delete  tables,  views,  records,  fields,  classes,  objects, 
instances,  attributes,  and  data.  Data  manipulation  includes  insert,  select,  update,  and  delete  tables, 
views,  records,  fields,  classes,  objects,  instances,  attributes,  and  data.  Data  query  includes  the 
ability  to  specify  search  conditions  consisting  of  a  combination  of  select  lists,  predicates,  and 
comparison  operators.  Data  integrity  includes  data  locking  (to  some  degree  of  granularity), 
consistency,  transaction  control  (to  specify  commit  and  rollback  commands  and  guarantee  the 
ability  to  serialize  database  transactions),  referential  constraints  (to  help  ensure  data  consistency), 
and  synchronous  writing  of  data.  Embedded  SQL  consists  of  SQL  statements  embedded  in  a  high- 
level  language  source  program.  In  a  separate  compiling  phase,  the  SQL  may  be  optimized  and 
converted  into  special  function  calls.  Dynamic  SQL  is  SQL  interpreted  by  the  SQL  database  at 
runtime.  Dynamic  SQL  may  be  generated  by  programs  or  entered  interactively  by  the  user. 
Facilities  embedded  in  application  programs  generate  executable  SQL  statements  during  program 
execution  so  control  of  a  database  can  be  turned  over  temporarily  to  the  end  user  for  interactive 
access  and  manipulation  of  data. 

3.4.1. 1.1  Standards.  Table  3.4-1  presents  standards  for  basic  database  services. 


TABLE  3.4-1  Basic  database  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Database  Language  SQL  (Adopts  ANSI  X3. 135-1992 
(same  as  ISO  9075: 1992)) 

mm 

Mandated 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

SQL  Environments 

FIPS  PUB 
193:1995 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Functional  Specifications  for  Database 
Management  Systems 

FIPS  PUB 
124:1986 

Informational 

(Approved) 

CPC 

X/Op® 

Embedded  SQL  (Cobol  and  Q 

Informational 

(Approved) 

IPC 

ISO 

Database  Language  -  Network  (NDL) 

8907:1987 

Informational 

(Approved) 

GPC 

NIST 

Database  Language  -  NDL  (adopts  ANSI  X3.133-1986) 

FIPS  PUB 
126:1987 

Informational 

(Approved) 

NPC 

ANSI 

Database  Language  -  (NDL) 

X3.133-1986 

Informational 

(Approved) 

CPC 

XTOpen 

Data  Management:  Reference  Model 

G505  (10/95) 

Informational 

(Approved) 

IPC 

ISO/IEC 

Database  Language  SQL 3  (will  replace  SQL2) 

9075 

Emerging 

(Draft) 

GPC 

NIST 

SQL  3 -Based  FIPS 

FIPS  PUB  127-3 

Emerging 

(Formative) 

NPC 

ANSI 

Database  Language  SQL3  (will  replace  SQL2) 

Hi 

Informational 

(Drift) 

CPC 

X/Opwi 

Structured  Query  Language  (SQL) 

C201  (9/92) 

Informational 

(Superseded) 

3.4.1.1.2  Alternative  specifications.  The  following  alternative  specifications  are  available: 

a.  For  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and 
dynamic  facilities  standards:  Integrated  Database  Application  Programming 
Interface  (IDAPI),  a  specification,  published  by  Borland,  IBM,  Novell,  and  Word 
Perfect  Corporation,  will  allow  DOS,  OS/2,  and  Windows  applications  to  access  a 
variety  of  SQL  and  non-SQL  databases  transparently. 

b.  No  applicable  consortia  or  de  facto  SQL  integrity  constraint  specifications  are 
available. 

c.  For  X/Open  SQL  and  the  IBM  Systems  Application  Architecture  (SAA)  SQL 
support  Embedded  C. 

d.  For  dynamic  facilities  the  only  other  available  specifications  are  proprietary. 

3.4.1. 1.3  Standards  deficiencies.  The  following  deficiencies  in  the  standards  have  been 
identified: 


a.  or  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and 
dynamic  facilities  standards: 
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(1)  No  standardized  way  exists  to  specify  logical  database  access  control, 
which  is  important  to  database  security. 

(2)  Hashing  methods  to  access  data  are  neither  standardized  nor  in  progress. 

(3)  SQL1  is  inadequate  and  has  failed  to  be  transportable  or  standardized  to  be 
very  useful.  The  upcoming  SQL-3  provides  an  opportunity  for  DOD 
requirements  to  be  ir-rted. 

b.  For  data  integrity  standards,  SQL  Integrity  Enhancement  is  a  simple  capability  with 
no  constructs  to  help  programmers  maintain  data  consistency. 

c.  For  Embedded  SQL  standards,  SQL2  supports  Embedded  SQL  in  C  and  Ada. 
However,  products  will  not  be  available  for  some  time.  International  Organization 
for  Standardization  (ISO)/American  National  Standards  Institute  (ANSI) 
Embedded  SQL  does  not  support  the  C  programming  language.  The  use  of 
embedded  SQL  requires  a  precompiler  for  each  language  in  which  SQL  is 
embedded. 

d.  For  dynamic  facilities  standards,  deficiencies  in  the  existing  formal  standards  are 
unknown. 

e.  For  SQL  environments,  the  emphasis  in  this  first  FIPS  for  SQL  Environments  is  on 
profiles  for  limited  SQL  interfaces  to  non-SQL  data  repositories.  Subsequent 
versions  of  this  FIPS  may  specify  more  complete  profiles  for  other  products  in  an 
SQL  environment  The  profiles  defined  by  this  standard  are  not  complete  in  and  of 
themselves.  The  user  is  required  to  add  information  before  this  standard  can  be 
successfully  used  in  a  procurement 

3.4. 1.1.4  Portability  caveats.  The  following  portability  caveats  apply: 

a.  For  data  definition,  manipulation,  query,  data  integrity,  embedded  SQL,  and 
dynamic  facilities  standards, 

(1)  SQL  2's  segmentation  into  multiple  levels  increases  the  likelihood  of 
incompatibility  between  different  vendors'  SQLs,  because  different  vendors 
will  implement  entry  level  SQL  2,  then  choose  options  from  other  levels. 

(2)  The  ISO,  ANSI,  and  Federal  Information  Processing  Standard  (FIPS) 
versions  of  SQL  specify  state  exception  code  values  (called  SQLCODE 
parameters)  such  as  0  for  successful  execution,  100  for  nonexistent  data, 
and  implementation  defined  code  values  for  particular  exception 
conditions.  Different  products  that  conform  with  SQL  have  different 
SQLCODE  values  for  exception  conditions.  The  set  of  SQL  character 
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values  for  the  character  data  type  and  collating  sequence  of  characters  is 
defined  by  the  implementor,  and  therefore,  nonstandard  in  products. 

b.  For  data  integrity  the  following  portability  caveats  apply: 

(1)  Most  vendors'  products  contain  extensions.  To  maximize  portability, 
reduce  the  use  of  extensions  as  much  as  possible. 

(2)  Different  vendors  provide  locking  to  different  degrees  of  granularity. 
Portability  and/or  interoperability  of  applications  result  in  locking  to  the 
largest  degree  of  granularity. 

c.  For  dynamic  facilities  the  following  portability  caveat  applies:  Although  the 
X/Open  and  SAA  SQLs  support  dynamic  SQL,  X/Open  SQL  is  an  X/Open- 
enhanced  specification  of  the  19S6  version  of  Level  1  SQL,  while  SAA  SQL  is  not 
fully  ISO/ANSI  SQL  compatible,  although  it  will  be.  Also,  X/Open  and  SAA 
dynamic  SQL  facilities  are  not  fully  compatible  with  each  other. 

d.  For  SQL  environments,  conformance  testing  for  products  claiming  conformance  to 
one  of  the  profiles  specified  by  FIPS  193  will  be  achieved  by  a  suitable 
modification  of  the  existing  NIST  SQL  test  suite.  This  FIPS  requires  the  customer 
to  choose  from  among  the  different  binding  styles  already  defined  by  the  SQL 
standards.  Two  of  these  styles  (CLI  and  RDA)  are  expected  to  be  more  popular 
than  the  others.  If  a  programming  language  binding  style  is  chosen,  then  FIPS  SQL 
specifies  the  parameter  passing  requirements  for  each  of  seven  different 
programming  languages. 


3.4. 1.1.5  Related  standards.  The  following  standards  are  related  to  basic  database  services  or 
basic  database  service  standards: 

(1)  ISO  9579-1:  Remote  Database  Access  (RDA)  (Generic  Model,  Service  and 
Protocol)(supports  remote  database  access  in  client-server  environments) 

(2)  ISO  9579-2:  RDA:  (SQL  Specialization) 

(3)  SQL  Access  Group's  (SAG's)  SQL  Access  Formats  and  Protocols  (FAP)  (1991) 

(4)  SAG's  Call  Level  Interface  (CLI) 

(5)  X/Open  RDA  Preliminary  Specification  (Identical  to  the  SAG's  RDA  Specification 

(6)  X/Open's  CLI  Snapshot  Specification  (Identical  to  the  SAG's  CLI  Specification) 
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(7)  Open  Systems  Interconnection  (OSI)  CCR  (Commitment,  Concurrency,  and 
Recovery):  ISO/Intemational  Electrotechnical  Commission  (EC)  9804-3/9805-3 

(8)  OSI  Distributed  Transaction  Processing  (DTP)  Protocol:  ISO/IEC  10026  Parts  1, 
2,  and  3. 

(9)  ISO  1989: 1985:  COBOL 

(10)  ANSI  X3.9-1978:  FORTRAN-77 

(11)  ANSIX3.159-1989:  C 

(12)  National  Institute  for  Standards  and  Technology  (NIST)  FIPS  021-3:  COBOL 

( 1 3)  NIST  FIPS  069- 1 :  FORTRAN 

(14)  NISTFIPS  119,  DODMIL-STD  1815A:1983,  ISO  8652:  Ada 

(15)  NISTFIPS  160;  C 

(16)  ISO/IEC  Draft  International  Standard  (DIS)  10032:  Reference  Model  of  Data 
Management 

(17)  ISO  12227  SQL/Ada  Models  Description  Language,  1994 

(18)  X3  SQLIB-1  SQL  Information  Bulletin  Number  1  Interpretation  of  ANSI  X.3.135 
-  1989 

3.4. 1.1.6  Recommendations.  The  following  are  related  to  data  definition,  manipulation,  query, 
data  integrity,  embedded  SQL,  and  dynamic  facilities  standards: 

(1)  Consult  the  wording  suggested  in  the  October  1991  General  Services  Agency 
(GSA)  publication  for  proposed  language  for  requiring  that  a  database  conform  to 
SQL,  and  consult  FIPS  127-2  for  guidance  on  how  to  structure  a  Request  for 
Proposal  (RFP),  The  FIPS  "flagger11  (to  flag  nonconforming  extensions)  is  optional 
and  must  be  specified  explicitly. 

(2)  If  interactive  SQL  is  required,  a  procurement  must  indicate  explicitly  whether  or 
not  "direct  invocation  of  SQL  statements"  is  required  and,  if  required,  which  SQL 
statements  are  to  be  directly  invocable.  If  not  specified,  the  default  is  "CREATE 
TABLE,"  "CREATE  VIEW,"  "GRANT  privilege,"  "SELECT"  with  "ORDER 
BY"  option,  "INSERT,"  "UPDATE:searched,"  "DELETE:searched,"  "COMMIT 
WORK,"  and  "ROLLBACK  WORK." 
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(3)  Explicitly  specify  sizing  constraints  for  database  constructs.  The  FIPS  1 27-2  sizing 
specifications  are  reasonable  to  expect  vendors  to  deliver,  but  are  fairly  minimal. 
Since  database  construct  sizing  specifications  depend  on  the  procurement,  a 
procurement  can  override  them. 

(4)  Require  the  use  of  NIST  conformance  tests  and/or  services  to  validate 
conformance  to  the  SQL-based  FTPS  for  required  and  optional  FIPS  127-2 
features.  Testing  applies  only  to  a  specific  platform,  so  call  for  conformance  tests 
for  each  platform  bid.  Use  the  quarterly  list  of  processors  validated  against  FIPS 
127-2  by  NIST  to  help  evaluate  bids. 

(5)  Specify  the  NIST's  Transition  Level  SQL  2  and  the  SAG's  CLI  and  RDA  interfaces 
and  protocols  for  the  following  reasons.  Most  DBMS  vendors  have  no  intention  of 
conforming  to  the  Full  Level  SQL  2: 1992  because  it  is  very  large  and  complex.  As 
a  result,  the  time  it  will  take  to  add  the  necessary  features  will  probably  exceed  the 
time  before  the  SQL  3  standard  is  completed.  To  ensure  portability  as  well  as 
functionality,  users  are  encouraged  to  include  the  following  two  specifications  in 
their  procurement: 

(a)  NIST's  Transition  Level  SQL  2  (specified  in  FIPS  127-2),  which  is  a  hybrid 
of  Entry  Level  and  higher  levels  of  SQL  2: 1992. 

(b)  SAG's  and  X/Open's  CLI  and  RDA  standards.  The  SAG  specifications  arc 
not  segmented  like  SQL  '92  and  offer  a  nice  balance  between  the  Full  Level 
SQL  '92  feature  set  and  what  users  need  now.  The  SAG  specifications 
include  connection  management  capabilities  (which  are  part  of  the  SQL  '93 
Fu'l  Level),  schema  manipulation  and  the  CHARACTER  VARYING  data 
type  (both  of  which  are  part  of  SQL  '93  Intermediate  Level),  and  features 
not  included  in  any  level  of  SQL  '92  conformance,  including  the  CREATE 
INDEX  and  DROP  INDEX  statements.  SAG's  specifications  are  published 
jointly  with  X/Open  as  X/Open  specifications. 

(6)  Specify  SQL2  (and  later  SQL3)  as  soon  as  possible  because  SQL2/3  contains 
greater  standardized  functionality  than  SQL1.  This  will  reduce  the  use  of 
nonstandard  extensions.  SQL2  also  standardizes  more  than  60  SQLCODE 
exception  code  values. 

(7)  Carefully  specify  and  check  all  sizing  constraints  for  a  procurement  to  meet 
functionality  requirements  and  avoid  portability  problems. 

(8)  Avoid  the  Network  Data  Language  (NDL),  if  possible,  because  it  is  little  used  and 
will  not  be  upgraded. 
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(9)  Specify  the  ISO  RDA  standard,  and  also  the  X/Open  or  SAG's  RDA  and  CLI 
specifications  in  conjunction  with  SQL/SQL2  to  obtain  remote  data  access 
capabilities  in  a  distributed  environment 

The  Integrity  Constraint  feature  is  optional  in  SQL  and  must  be  specified  explicitly  for  a 
procurement  Failure  to  do  so  means  the  Integrity  Constraint  feature  is  not  required.  Specify  FIPS 
127-2,  especially  if  any  of  the  services  unique  to  FIPS  127-2  are  needed. 

In  SQL2,  the  integrity  enhancement  feature  is  mandatory,  not  optional.  Also,  SQL2  has  better 
integrity  constraints,  such  as  "cascade  delete  on  referential  integrity"  (in  the  intermediate  SQL 
Level)  and  "deferrable  integrity  constraints"  (in  full  SQL2). 

For  embedded  SQL: 

(1)  Specify  embedded  SQL  in  an  RFP,  although  it  is  optional  in  the  standard.  Indicate 
which  programming  language  is  to  be  supported  in  references  to  embedded  SQL  in 
a  procurement.  Failure  to  do  so  means  that  support  for  any  one  FIPS  language 
satisfies  the  FIPS  SQL  requirement.  Indicate  whether  the  language  interface  is  to 
support  the  Module  Language  interface  style,  the  embedded  language  interface 
style,  or  both.  Failure  to  do  so  mear.s  that  vendors  supporting  any  one  interface 
style  satisfy  the  FIPS  SQL  requirement 

(2)  Require  the  use  of  NIST  conformance  tests  and/or  services  to  validate 
conformance  to  every  one  of  the  embedded  interfaces  and  module  interfaces,  and 
to  validate  the  compilers  that  will  be  used  with  the  embedded  SQL  because  SQL 
testing  is  independent  of  the  host  programming  language  testing.  Testing  applies 
only  to  a  specific  platform,  so  call  for  conformance  tests  for  each  platform  bid. 
Specify  FIPS  127-2  if  any  of  the  services  unique  to  FIPS  127-2  are  needed. 

Specify  that  the  character  data  values  and  collating  sequences  coincide  with  the 
character  values  and  collating  sequence  of  the  specific  programming  languages  to 
be  used.  Failure  to  indicate  specific  character  set  requirements  means  that  support 
for  representation  of  the  95-character  graphic  subset  of  American  Standard  Code 
for  Information  Interchange  (ASCII)  (FIPS  1-2)  in  an  implementor  specified 
collating  sequence  defaults  to  the  minimum  requirement,  and  may  not  be  portable 
across  other  procured  systems. 

For  dynamic  facilities,  SQL2  is  preferred.  Dynamic  SQL  is  an  intermediate  level  SQL2  capability. 
Either  SQL2's  dynamic  SQL  facilities  or  the  SQL2  intermediate  level  must  be  specified  explicitly 
in  a  procurement. 

For  SQL  Environments,  the  FIPS  is  applicable  in  any  situation  where  it  is  desirable  to  integrate 
user  productivity  tools  and  heterogeneous  data  repositories  into  an  SQL  environment.  It  is 
particularly  suitable  for  specifying  limited  SQL  interfaces  to  legacy  databases  or  to  specialized 
data  repositories  such  as  geographic  information  systems,  full-text  document  management 
systems,  or  object  database  management  systems. 
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3. 4. 1.2  Indexed  sequential  access.  The  Indexed  Sequential  Access  Method  (ISAM)  is  a 
procedure  for  storing  and  retrieving  data  from  a  disk  file.  When  the  programmer  designs  the  file 
format,  a  set  of  indices  is  created  describing  where  the  records  of  the  file  are  located  on  the  disk. 
This  provides  a  quick  method  of  retrieving  the  data  and  eliminates  the  need  to  read  all  data  from 
the  beginning  to  find  the  desired  information.  The  indexes  can  be  stored  as  part  of  the  data  file  or 
in  a  separate  index  file.  The  sequential  order  will  be  the  one  most  commonly  used  for  batch 
processing  and  printing  (e.g.,  account  number,  name). 

3.4.1.2.1  Standards.  Table  3.4-2  presents  standards  for  indexed  sequential  access. 


TABLE  3.4-2  Indexed  sequential  access  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

DtU  Minegement,  Iitue  3 

C2I5  (3/92) 

Adopted 

(Approved) 

CPC 

X/Opeo 

Indexed  Sequent)*]  Access  Method  (ISAM):  Developen' 
Specification 

D010  (8/90) 

Adopted 

(Approved) 

3.4.1.2.2  Alternative  specifications.  Another  specification  option  is  Informix  Software  Inc.'s  C- 
ISAM,  on  which  X/Open's  ISAM  is  based. 

3.4. 1.2.3  Standards  deficiencies.  The  greatest  deficiency  in  ISAM  standards  is  the  lack  of  any 
formal  ISAM  specifications  or  functionality. 

3.4.1.2.4  Portability  caveats.  Consider  the  use  of  ISAM  carefully  as  risks  are  involved  in  using 
an  informal  standard. 

3.4.1.2.5  Related  standards.  The  following  standards  are  related  to  ISAM  or  ISAM  standards: 

a.  ISO  9075:  SQL 

b.  ISO  9579-1:  RDA  (Generic  Model,  Service  and  Protocol 

c.  ISO  9579-2:  RDA  (SQL  Specialization) 

d.  ANSI  X3. 135- 1992:  SQL 

e.  NIST  FIPS  127-2:  SQL 

f.  NIST  FIPS  193:  SQL  Environments 

3.4.1.2.6  Recommendations.  When  specifying  ISAM  services,  all  ISAM  systems  offered  as  a 
result  of  a  procurement's  requirements  should  be  integrated  with  the  SQL  database  language  set 
forth  in  FIPS  PUB  127-2,  and  should  implement  all  of  the  features  specified  elsewhere  in  this 
document.  All  ISAM  systems  offered  as  a  result  of  a  procurement's  requirements  should  be 
integrated  with  ISO  9579-1 :  RDA  (Generic  Model,  Service  and  Protocol).  If  SQL  is  used,  it  also 
should  be  integrated  with  ISO  9579-2:  RDA  (SQL  Specialization).  Carefully  weigh  the  portability 
risks  in  specifying  ISAM,  because  only  consortia  ISAM  standards  exist. 
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3.4.1.3  Electronic  forms.  (This  BSA  appears  in  part  3,  User  Interface,  part  4,  Data 
Management,  and  part  3,  Data  Interchange.)  These  standards  specify  the  functional  interface 
requirements,  transfer  of  various  fields  and  the  interface  between  programming  languages  and 
form  filling  applications  for  use  on  a  terminal  display. 

3.4.1.3.1  Standards.  Table  3.4-3  presents  standards  for  electronic  forms. 


TABLE  3.4-3  Electronic  forms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

DOD  Standardized  Electronic  Form*  Requirement* 

JffiO-E-2300 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Form*  Interface  Management  Syrian  (FIMS) 

11730:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Open  Syrian  Interconnection  Profile  (GOSIP 
2):  Virtual  Terminal  Bonn*  Claai  Profile 

FIPS  PUB  146- 
1:1991 

Informational 

(Approved) 

CPC 

X/Op« 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Utilities  Iitue  4,  Venion  2  (pail  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

CPC 

X/Open 

C437  (2/95) 

Emerging 

(Approved) 

GPC 

DOD 

DOD  Form*  Management  Program  Procedure*  Manual 

DOD  7750.7-M 

Informational 

(Approved) 

CPN-C 

Numerous 

vendor* 

Query  by  Form* 

Query  by  Form* 

Informational 

(Approved) 

IPC 

iso/mc 

OSI  Virtual  Terminal  Ba*ic  Cla»»  Service,  Amendment  2: 
Additional  Functional  Unit*  (form*  capability) 

9040:1990  DAM  2 

Informational 

(Draft) 

IPC 

ISOAEC 

OSI  Virtual  Terminal  (VT)  Basic  Cla*i  Protocol,  Part  1, 
Amendment  2:  Additional  Functional  Unit*  (Form* 
Capability) 

9041-1:1990  DAM 

2 

Informational 

(Draft) 

CPC 

X/Open 

Internationalized  Terminal  Interface*  (XCURSES),  U*ue4 

S422  (4/94) 

Informational 
(Super*  eded) 

3.4. 1.3.2  Alternative  specifications.  The  Berkeley  Software  Distribution  (BSD)  4.2/4.3  UUN1X 
Curses  are  also  available. 

3.4. 1.3.3  Standards  deficiencies.  The  X/Open  Portability  Guide  4  (XPG4)  Curses  is  based  on 
the  System  V  Interface  Definition  (SVID)  Issue  2  Curses  version,  which  does  not  include  the 
SVID's  forms  and  menu  libraries. 

Forms  Class  Virtual  Terminal  has  bindings  in  C  only. 

DOD  has  developed  a  specification  for  electronic  forms  (Joint  Interoperability  and  Engineering 
Organization  (JIEO)-E-2300).  It  defines  the  minimum  operational  requirements  for  electronic 
forms  software  and  mandates  an  interchange  file  format  based  on  Forms  Interface  Management 
System  (FIMS). 
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3.4.1.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.4. 1.3.5  Related  standards.  The  Forms  Class  Virtual  Terminal  requires  the  Synchronous  mode 
(S-mode)  of  operation  and  specifies  simple  delivery  control.  The  following  standards  are  related 
to  forms  query  and  management: 

a.  ISO  9075:  SQL 

b.  ANSI  X3. 135- 1992:  SQL2 

c.  NIST  FIPS  127-2:  SQL 

d.  NIST  FIPS  193:  SQL  Environments 

3.4.1.3.6  Recommendations.  The  recommended  standard  is  JIEO-E-2300.  For  User  Interface, 
FIMS  should  be  considered.  For  Data  Management,  make  sure  the  forms  management  systems 
are  compatible  with  FIPS  127-2  SQL.  Database  forms  management  systems  should  be  integrated 
with  the  SQL  database  language  and  formats  set  forth  in  FIPS  PUB  127-2. 
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3.4. 1.4  Report  writer.  A  report  writer  is  an  application  that  prints  a  report  based  on  a 
description  of  the  layout  As  a  stand-alone  program  or  part  of  a  DBMS,  it  retrieves  selected 
records  from  a  file  and  may  sort  them  into  a  new  sequence  before  printing.  Once  created,  it  is 
stored  in  a  report  file  for  future  use. 

Nonprocedural  forms  management  includes  forms  creation,  modification,  and  management 
including  screen  painting.  Procedural  forms  management  includes  forms  creation,  modification, 
and  management  using  procedural  methods.  A  nonprocedural  report  writer  includes 
nonprocedural  formatted  database  report  definition,  modification,  and  management.  A  procedural 
report  writer  includes  formatted  database  report  definition,  modification,  and  management  using 
procedural  techniques, 

3.4.1.4.1  Standards.  Table  3.4-4  presents  report  writer  standards. 


TABLE  3.4-4  Report  writer  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

Non*. 

N.A. 

Information*] 

(N.A.) 

3.4.1.4.2  Alternative  specifications.  The  only  available  specifications  are  proprietary,  such  as 
IBM's  SAA  RPG:  Common  Programming  Interface:  Database  Reference  (SC09- 1286-01). 

3.4.1.4.3  Standards  deficiencies.  The  lack  of  procedural  or  nonprocedural  capabilities  for 
database  report  writing  is  the  deficiency  in  open  standards  for  report  writers. 

.3.4. 1.4.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.4.1.4.5  Related  standards.  The  following  standards  are  related  to  report  writers  or  report 
writer  standards: 

a.  ISO  9075:  1992  -  Database  Languages  -  SQL,  Third  Edition 

b.  ANSI  X3. 135- 1992:  SQL 

c.  NIST  FIPS  127-2:  SQL 

d.  NIST  FIPS  1 93:  SQL  Environments 

e.  (see  also  Fourth  Generation  Language  under  Software  Engineering  Services) 

3.4. 1.4.6  Recommendations.  All  database  report  writing  systems  should  be  integrated  with  the 
SQL  database  language  set  forth  in  FIPS  PUB  127-2  and  the  SQL  Environments  of  FIPS  193. 
The  lack  of  procedural  or  nonprocedural  capabilities  for  database  report  writing  is  a  deficiency  in 
open  database  standards. 
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3.4.1.5  Database  administration.  (This  BS A  appears  in  part  4  and  part  9.)  Data  administration 
is  the  process  of  the  analysis,  classification,  and  maintenance  of  an  organization's  data  and  data 
relationships’  It  includes  the  development  of  data  models,  data  warehousing,  and  data  dictionaries, 
which  com  with  transaction  processing,  are  the  raw  materials  for  database  design. 

3.4.I.5.1  Standards,  Table  3.4-5  presents  standards  for  database  administration. 


TABLE  3.4-5  Database  administration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

DaU  Element  Standardization  Procedure*,  January  1993 

Manual  8320. 1-M- 
I 

Mandated 

(Approved) 

GPC 

NIST 

Guide  to  DaU  Entity  Naming  Convention* 

NBS  SP  500-149  of 
Oct.  1987 

Informational 

(Approved) 

GPC 

DOD 

Defease  DaU  Repository  System 

End  User  Manual 
ver.  2.0  of  10 
August  1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Specification  and  Standardization  of  DaU  Elements,  Part  3: 
Basic  Attributes  of  DaU  Element* 

11179-3:1994 

Informational 

(Approved) 

IPC 

ISO/EC 

Specification  and  Standardization  of  DaU  Elements,  Part  4: 
Rules  and  Guidelines  for  (be  Formulation  of  Data 
Definitions 

11179-4:1995 

Information*] 

(Approved) 

IPC 

ISO/IEC 

Specification  and  Standardization  of  DaU  Elements,  Part  S: 
Naming  and  Identification  Principles  for  DaU  Elements 

11179-5:1995 

Informational 

(Approved) 

IPC 

iso/mc 

Specification  and  Standardization  of  DaU  Elements,  Part  6: 
Registration  of  DaU  Element* 

11179-6 

Informational 

(Draft) 

GPC 

DOD 

DOD  DaU  Administration 

DODD  8320.1  of 
9/26/1991 

Informations! 

(Superseded) 

3. 4. 1.5. 2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary 
database  utilities. 

3.4.1.5.3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  service : 
are  not  part  of  any  formal  standard. 

3.4. 1.5.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.4.1.5.5  Related  standards.  The  following  standards  are  related  to  database  administration  or 
database  administration  standards: 

a.  ISO  7498-4: 1 989:  Management  Framework 

b.  ISO  9075:  SQL 

c.  ISO  9579-1:  RDA  (Generic  Model,  Service  and  Protocols) 

d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9595: 1991 :  CMIS. 

f.  ISO  9596-1: 1991:  CMIP. 

g.  ISO/IEC  9945-1:  (IEEE  PI 003.1) 
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h.  ISO  10164-1:1993:  Object  Management  Function 
L  ISO  10165-1:1991:  SMI  -  Part  1  Management  Information  Model 

j.  ISO  10165-2:1991:  SSM1  -  Part  2  DMI 

k.  ISO  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects  (GDMO) 

L  ANSI  X3. 135- 1992:  SQL 

m.  ANSI  X3.168-1989:  Embedded  SQL 

n.  NIST  FIPS  127-2:  Database  Language  SQL 

o.  NIST  FIPS  146-1:  Government  Open  Systems  Interconnection  Profile  (GOSIP) 

p.  NIST  FIPS  156:  IIRDS 

q.  NIST  FIPS  193:  SQL  Environments 

3.4.1.5.6  Recommendations.  DODD  8320.)  is  recommended  for  data  administration.  Database 
administration  systems  should  be  comratible  with  and  integrated  with  the  SQL  database  language 
set  forth  in  FIPS  PUB  127-2.  Furthermore,  all  database  administration  systems  offered  as  a  result 
of  this  procurement's  requirements  shall  be  integrated  with  ISO  9579-1  RDA  (Generic  Model, 
Service  and  Protocol),  ISO  9579-2  Remote  Database  Access  (SQL  Specialization)  of  December 
1993,  and  NIST  FIPS  PUB  193,  SQL  Environments. 
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3.4.1.6  Menu-driven  database  access.  These  standards  provide  access  to  a  database  through  a 
menu-driven  or  form-filling  interface. 

3.4.1.6.1  Standards.  Table  3.4-6  presents  standards  for  menu-driven  database  access. 


TABLE  3.4-6  Menu-driven  database  access  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

DOD  SUcdardued  Electronic  Form*  Requirements 

JIEO-E-2300 

Informational 

(Approved) 

IPC 

ISO/IEC 

Forms  Interface  Management  System  (FIMS) 

11730:1994 

Informational 

(Approved) 

3.4.1.6.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.1.6.3  Standards  deficiencies.  The  FIMS  is  not  specific  to  database  management  systems, 
instead,  it  is  a  generic  programming  language  for  building  generic  forms.  No  menu-driven 
database  access  standard  either  exists  or  is  emerging. 

3.4.1.6.4  Portability  caveats.  When  completed,  FIMS  will  apply  to  many  types  of  applications, 
and  is  related  only  generically  to  database  forms  and  menus.  Consequently,  programs  built  using 
FIMS  have  a  high  probability  of  not  being  compatible  with  a  particular  database,  or  with 
interconnected  databases. 

3.4. 1.6.5  Related  standards.  The  only  standard  related  to  menu-driven  database  access  or  menu- 
driven  database  access  standards  is  Open  Software  Foundation  (OSF):  Motif. 

3.4.1.6.6  Recommendations.  JIEO-E-2300  is  recommended. 
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3.4.1.7  Data  storage  and  archiving.  Data  storage  and  archiving  services  provide  a  database 
application  with  the  facilities  for  temporary  storage  and  long-term  data  archiving.  Archiving  flies 
is  a  process  in  which  the  information  contained  in  an  active  computer  file  is  made  ready  for 
storing  in  a  nonactive  file,  perhaps  in  off-line  or  near-line  storage.  Typically  when  files  are 
archived,  they  are  compressed  to  reduce  their  size.  To  restore  the  file  to  its  original  size  requires  a 
process  known  as  unarchiving. 

3.4.1.7.1  Standards.  Table  3.4-7  presents  standards  for  data  storage  and  archiving. 


TABLE  3.4-7  Data  storage  and  archiving  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Infonnatioojd 

(N.A.) 

3.4.1.7.2  Alternative  specifications.  The  only  available  specifications  are  proprietary 
specifications  and  database  utilities. 

3.4.1.7.3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.4. 1.7.4  Tailoring  guidance.  No  tailoring  guidance  is  available  because  no  standards  exist. 

3.4. 1.7 £  Related  standards.  The  following  standards  are  related  to  data  storage  and  archiving  or 
data  storage  and  archiving  standards: 

a.  ISO  9595:1991:  CM1S 

b.  ISO  9596:1991:  CMIP 

c.  Forthcoming  UNIX  International  specification  for  backup  and  archive 
3.4.1.7.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.4. 1.8  Multidatabase  Application  Program  Interfaces.  Multidatabase  Application  Program 
Interface  (APIs)  specify  the  interaction  among  several  heterogeneous  databases. 

3.4.1.8.I  Standards.  Table  3.4-8  presents  standards  for  multidatabase  application  program 
interfaces. 


TABLE  3.4-8  Multidatabase  Application  Program  Interfaces  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPN-C 

Microsoft 

Open  DftUbue  Connectivity  (ODBC)  10 

ODBC 

Wad dated 
(Approved) 

CPN-C 

Microsoft 

Open  DtUbue  Coooectivity(ODBC)  3.0 

ODBC 

Emerging 

(Drift) 

CPN-C 

Sub 

Java  PAUbAte  Connectivity  (JDBC) 

JDBC 

Inform  atiooaJ 
(FormAtive) 

3.4.I.8.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary 
database  utilities. 


3.4. 1. 8 3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown. 

3.4.1.8.4  Portability  caveats.  Portability  caveats  in  the  standards  are  unknown. 

3.4.1.8.5  Related  standards.  All  standards  for  a  single  database  are  related  to  multidatabase  API 
standards. 

3.4.1.8.6  Recommendations.  ODBC  is  recommended  for  this  Base  Service  Area. 


I 
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3.4. 1.9  Models/Process/Workflow.  Information  standards  in  this  BSA  address  activity  models, 
data  models  and  workflow.  The  information  requirements  identified  in  the  activity  model  is  used 
as  the  basis  for  developing  a  fully  attributed  data  model.  The  data  model  identifies  the  logical 
information  requirements  and  metadata,  which  forms  a  basis  for  physical  database  schema  and 
data  elements.  Workflow  defines  the  functionality  required  to  support  interoperabilty  between 
workflow  products. 

3.4.1.9.1  Standards.  Table  3.4-9  presents  standards  for  models/process/workflow. 


TABLE  3.4-9  Models/Process/Workflow  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Integration  Definition  for  Information  Modeling  (I DEFIX) 

FIPS  PUB  184 

Mandated 

(Approved) 

GPC 

NIST 

Integration  Definition  for  Function  Modeling  (IDEH)) 

FIPS  PUB  183 

Mandated 

(Approved) 

CPC 

WFMC 

Interoperability  Aba  tract  Specification 

WFMC-TC- 

1012:1996 

Informational 

(Approved) 

NPC 

TKKF 

Conceptual  Schema  Modeling  for  Object  Oriented 

IDEF1X97 

Informational 

(Draft) 

CPC 

WFMC 

Interface  5  Audit  Specification 

TC1015 

Informational 

(D«ft) 

CPC 

WFMC 

Application  Program  Interface 

WFMC-TC-1009 

Informational 

(Draft) 

3.4.1.9.2  Alternative  specification.  The  only  other  available  specifications  are  proprietary. 

3.4. 1.9 .3  Standard  deficiencies.  Deficiencies  in  the  standards  are  unknown. 

3.4. 1.9.4  Portability  caveats.  Portability  problems  with  the  standards  are  unknown. 

3.4.1.9.5  Related  standards.  No  related  standards  are  known  at  this  time. 

3.4.1.9.6  Recommendations.  The  mandated  specifications  are  recommended. 
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3.4.2  Data  management  security.  Security  for  data  management  services  encompasses  access 
control  mechanisms  for  data  that  is  either  stored  or  manipulated  in  a  database  management 
system.  In  addition  to  access  control,  labeling  and  integrity  concerns  must  be  addressed.  Programs 
and  data  can  be  secured  by  issuing  identification  numbers  and  passwords  to  authorized  users  of  a 
computer.  Passwords  can  be  checked  in  the  DBMS  software,  where  each  user  can  be  assigned  an 
individual  view  (subschema)  of  the  database.  Although  precautions  can  be  taken  to  detect  an 
unauthorized  user,  determining  whether  a  valid  user  is  performing  unauthorized  tasks  is  extremely 
difficult 

3.4.2.1  Database  security.  (This  BSA  appears  in  part  4,  part  9,  and  part  10.)  Database  security 
standards  provide  protection  for  stored  data  from  unauthorized  access,  modification,  and  denial  of 
service. 

3.4.2.1.1  Standards.  Table  3.4-10  presents  standards  for  database  security. 


TABLE  3.4-10  Database  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Tiusted  Computer  Systems  Evaluation  Criteria 

NCSC-TO-021. 
Version  1: 1991 

Mandated 

(Approved) 

n*c 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(tame  uCCITrX.800: 1991) 

7498-2:1989 

Informational 

(Approved) 

OPC 

NIST 

HUM 

FIPS  PUB  127- 

2:1993 

Informational 

(Approved) 

OPC 

NIST 

Information  Resource  Dictionary  System  (IRDS)  (adopts 
ANSI  X3. 138- 1988  and  X3.138A-1991) 

FIPS  PUB 
156:1989 

Informational 

(Approved) 

NPC 

ANSI 

Database  Language  SQL 

X3. 135- 1992 

Informational 

(Approved) 

IPC 

ISO 

Database  Language  SQL  (same  as  ANSI  X3. 135- 1992) 

9075:1992 

Informational 

(Approved) 

IPC 

iso/mc 

Information  Resource  Dictionary  System  (IRDS) 
Framework 

10027:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Service  Definition  for  the  Commitment,  Concurrency, 
and  Recovery  (CCR)  Service  Element 

9804:1990 

Informational 

(Approved) 

IPC 

1SO/IEC 

OSI  Protocol  Specification  for  the  Commitment, 
Concurrency,  and  Recovery  (CCR)  Service  Element 

9805:1990 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 

X3.138-1988 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface  Amendment  1 :  C  Language  Binding 

10728  AMD 
1:1994 

Informational 

(Draft) 

3.4.2.1.2  Alternate  specifications.  No  alternate  specifications  are  known. 

There  are  no  alternative  specifications. 

3.4.2.1.3  Standards  deficiencies.  Deficiencies  in  \  c  existing  standard  are  unknown. 
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3.4.2. 1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.4.2. 1.5  Related  standards.  DOD  5200.28-STD,  26  December  1995,  DOD  Trusted  Computer 
Systems  Evaluation  Criteria,  is  related  to  NCSC-TG-021.  The  following  specifications  are  related 
to  DOD  5200.28-STD: 


a.  NCSC-TG-018,  Version  I,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in 
Trusted  Systems 

b.  NCSC-TG-025,  Version  2,  September  1991,  A  Guide  to  Understanding  Data 
Remnants  in  Automated  Information  Systems 

3.4.2.1.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.4.2 2  System  access  control.  (This  BSA  appears  in  part  4,  part  9,  part  10,  and  part  11.) 
System  access  control  standards  provide  high-level  guidance  on  access  control  frameworks  and 
implementation. 

3.4.2.2.I  Standards.  Table  3.4-1 1  presents  standards  for  system  access  control. 


TABLE  3.4-11  System  access  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trusted  Computer  Sy items  Evaluation  Criteria 

DOD  5200.28. 
STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

Diiuibuted  Computing  Environment  (DCK)  Security 
Service* 

DCS  1.1  Security 
Service*:  1994 

Mandated 

(Approved) 

CPC 

QSF 

Diiuibuted  Computing  Environment  (DCK)  Rev.  1,2.2 

DCF.  Rev. 

1.2.2:1996 

Informational 

(Approvod) 

IPC 

ISO 

7498-2:1989 

Informational 

(Approved) 

(PC 

ISO/tEC 

OSI  Common  Management  Information  Service*  (CMIS) 
Definition,  with  Amendment  4:  Aoceu  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/DBC 

10164.9:1995 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  .Security 
Evaluation,  (CC)  Vernon  1.0 

CC  Vernon  1.0: 
1996 

Emerging 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Framework*  in  Open  Syitemi,  Part  3:  Accen 
Control 

10181.3 

Informational 

(Draft) 

3.4.2.2.2  Alternate  specifications.  No  alternate  specifications  are  known. 

There  are  no  alternative  specifications. 

3.4.2.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.4.2.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.4.2.2.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 

a.  NCSC-TG-003,  Version  1,  September  1987,  A  Guide  to  Understanding 
Discretionary  Access  Control  in  Trusted  Systems 

b.  NCSC-TG-028,  Version  1,  May  1992,  Assessing  Controlled  Access  Protection 

c.  NCSC-TG-020-A,  August  1989,  Trusted  UNIX  Working  Group  (TRUSD() 
Rationale  for  Selecting  Access  Control  List  Features  for  the  UNIX  System 

3.4.2.2.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.4.23  Data  management  security  labeling.  (This  BSA  appears  in  part  4  and  part  10.)  Data 
management  security  labeling  provides  a  security  service  for  ensuring  that  data  includes  labeling 
information  in  support  of  mandatory  access  control  security  services,  marking  security  services, 
handling  security  services,  aggregation  security  services,  sanitization  security  services,  and  release 
security  services.  Security  labeling  services  produce  and  maintain  the  integrity  of  the  security  label 
and  its  binding  to  tire  data  with  which  it  is  associated. 

3.4J.3.1  Standards.  Table  3.4-12  presents  standards  for  data  management  security  labeling. 


TABLE  3.4-12  Data  management  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trotted  Computer  Syttemi  Evolution  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-6216- 

91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  Uter  Interface 
Guideline#,  Revition  1 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Woriutatioo  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

3.4.2 .3.2  Alternate  specifications.  There  are  no  alternative  standards. 

3.4.2.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.4.2.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.4.2.3.5  Related  standards.  Data  management  security  labeling  should  be  compatible  with  MDL- 
STD-2045-48501,  Common  Security  Label,  for  any  system  with  a  communications  interface. 

DOD  5200. 1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information. 

3.4.2.3.6  Recommendations.  The  mandated  standard  is  recommended.  Data  management 
security  labeling  should  be  based  of  the  operating  system  security  label  standards.  Data 
management  security  labeling  should  employ  binding  of  strength  equal  to  or  greater  than  that  of 
the  operating  system.  Compatible  security  labeling  standards  include  the  ability  to  perform  a  one- 
for-one  mapping  or  translation  between  security  labeling  standards. 
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3.4.2.4  Systems  integrity.  (This  BSA  appears  in  part  4  and  part  10.)  Systems  integrity 
objectives  ensure  the  integrity  of  information  and  resources  by  providing  a  level  of  protection  in 
response  to  the  threats  of  unauthorized  modification,  manipulation,  and  destruction  which  is 
commensurate  with  the  importance  and  priority  of  the  content  These  standards  provide  the  high- 
level  framework  with  which  to  view  the  security  service  of  integrity  in  open  systems. 

3.4.2.4.1  Standards.  Table  3.4-13  presents  standards  for  system  integrity. 


TABLE  3.4-13  Systems  integrity  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD 

The  DOD  Trusted  Computer  System*  Evaluation  Criteria 

DOD  5200.28' 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trailed  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC.T0.021. 
Version  1: 1991 

Mandated 

(Approved) 

IPC 

ISO 

muBgmiijjB 

7498-2:1989 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

IPC 

ISO/tEC 

10181-6 

Informational 

(Draft) 

IPC 

ITU-T 

X.815:  1993 

Informational 

(Draft) 

3.4.2.4.2  Alternate  specifications.  No  alternate  specifications  are  known. 

There  are  no  alternative  specifications. 

3.4.2.4.3  Standards  deficiencies.  Deficiencies  in  the  existing  standard  are  unknown. 

3.4.2.4.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.4.2.4.5  Related  standards.  The  following  NS  A  documents  supplement  the  information  on 
integrity  found  in  the  TCSEC: 

a.  C  Technical  Report  79-91,  September  1991,  "Integrity  in  Automated  Information 
Systems: 

b.  C  Technical  Report  111-91,  October  1991,  "Integrity-Oriented  Control 
Objectives:  Proposed  Revisions  to  the  Trusted  Computer  System  Evaluation 
(TCSEC).  DOD  5200.28-STD." 

3.4.2.4.6  Recommendations.  The  mandated  standards  are  recommended. 
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S.4.2.5  Data  integrity  techniques.  (This  BSA  appears  in  part  4  and  part  10.)  Data  integrity 
techniques  provide  services  that  allow  data  integrity  between  communicating  applications  to  be 
confirmed  by  means  of  a  cryptographic  check  function  using  a  block  cipher  algorithm,  by 
electronic  signature,  electronic  hashing,  and  encryption. 

3. 4.2. 5.1  Standards.  Table  3.4-14  presents  standards  for  data  integrity  techniques. 


TABLE  3.4-14  Data  integrity  techniques  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Sectue  Huh  Standard  (SHS) 

FIPS  PUB  180- 
1:1995 

Mandated 

(Approved) 

GPC 

NIST 

Dlgiul  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

IPC 

ISO 

Data  Cryptographic  Technique*  •  Data  Integrity 
Mechanim  Uling  a  Cryptographic  Check  Ruction 
Employing  a  Block  Cipher  Algorithm 

9797:1989 

Informational 

(Approved) 

CPC 

IETF 

IP  Authentication  Header  (AH) 

RFC  1826: 1995 

Emerging 

(Draft) 

CPC 

IETF 

IP  Encapsulating  Security  Payload  (ESP) 

RFC  1827:  1995 

Emerging 

(Draft) 

CPC 

IETF 

Domain  Name  System  (DNS)  Security  Extensions 

RFC  2065:1997 

Emerging 

(Draft) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB 
180:1993 

Informational 

(Superseded) 

3.4.2.S.2  Alternate  specifications.  Alternative  de  facto  specifications  include  RSA  and  MD-5. 
3.4.2.S 3  Standards  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.4.2.5.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.4.2.5.5  Related  standards.  There  are  no  related  standards. 

3.4.2.5.6  Recommendations.  The  mandated  standards  are  recommended. 

FIPS  PUB  180-1,  which  supersedes  FIPS  PUB  180,  specifies  a  Secure  Hash  Algorithm  (SHA-1) 
which  can  be  used  to  generate  a  message  digest.  The  SHA- 1  is  required  for  use  with  the  Digital 
Signature  Algorithm  (DSA)  as  specified  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  in 
federal  applications. 
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3.4.3  Data  dictionary /directory  services.  Data  dictionary/directory  services  are  key  computer 
software  tools  that  manage  data  and  information  resources.  Such  services  provide  extensive 
facilities  for  recording,  storing,  and  processing  descriptions  of  an  organization's  significant  data 
and  data  processing  resources,  and  often  provide  facilities  to  use  metadata  (information  about 
data). 

3.4.3.I  Data  dictionary.  (This  BSA  appears  in  part  4  and  part  9.)  A  data  dictionary  is  a  part  of 
a  database  management  system  that  transparently  provides  a  centralized  meaning,  relationship  to 
other  data,  origin,  usage,  and  format.  It  also  indicates  which  application  programs  use  that  data, 
so  that  when  a  change  in  a  data  structure  is  contemplated,  a  list  of  affected  programs  can  be 
generated.  The  data  dictionary  a  stand-alone  system  or  may  be  an  integral  part  of  the  DBMS  and 
used  to  control  it.  Data  integrity  and  accuracy  is  better  ensured  in  the  latter  case. 

3.4J.I.1  Standards.  Table  3.4-13  presents  data  dictionary  standards. 


TABLE  3,4-15  Data  dictionary  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Inform  ad  on  Resource  Dictionary  System  (IRDS)  (adopts 
ANSI  X3. 138-1988  and  X3. 138 A- 1991) 

FIPS  PUB 
156:1989 

Adopted 

(Approved) 

IPC 

ISO/IKC 

Information  Resource  Dictionary  System  (IRDS) 
Framework 

10027:1990 

Informational 

(Approved) 

GPC 

NIST 

Guide  for  the  Development,  Implementation,  and 
Maintenance  of  Standards  for  the  Representation  of 
Computer  Processed  Data  Elements 

FIPS  PUB  45:1976 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Planning  and  Using  a  Data  Dictionary 
System 

FIPS  PUB  76:1980 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 

X3.I38-1988 

informational  | 
(Approved)  | 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface 

X3. 185- 1992 

Informational  j 
(Approved)  | 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 

Expo rl/lm port  File  Format 

X3.I95-1991 

Informational  | 
(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface 

10728:1993 

Informational 

(Approved) 

CPC 

Metadata 

Coalition 

Metadata  Interchange  Specification  (MDIS) 

MDIS  1.0:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
interface  Amendment  1:  C  Language  Binding 

10728  AM' 
1:1994 

informational 

(Draft) 

IPC 

ISO/IEC 

information  Resource  Dictionary  System  (IRDS) 
Export/Import  Support  for  SQL:  1989  with  Integnty 
Enhancement 

JTCI/SC21/VvG03 

Nxxx 

Informational 

(Formative) 

IPC 

ISO/IEC 

information  Resource  Dictionary  System  (IRDS)  Design 
Support  for  SQL  Applications 

JTC1/SC21/WG03 

Nxxx 

Informations! 

(Draft) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface  Amendment  2:  Ada  bindings  (binding  for  Ada-83) 

10728  WDAM 
2:19930*) 

Informational 

(Draft) 
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3.4.3.I.2  Alternative  specifications.  No  applicable  consortia  or  de  facto  specifications  for  the 
data  dictionary  are  available. 

3.4.3. 13  Standards  deficiencies.  The  following  deficiencies  have  been  identified  in  the  available 
standards: 

a.  APIs  with  the  IRDS  are  not  currently  defined. 

b.  There  are  no  IRDS  bindings  to  Ada. 

c.  IRDS  does  not  support  the  development  of  active  functionality. 

d.  IRDS  does  not  support  object-oriented  data  structures.  An  upcoming  major  IRDS 
revision  is  expected  to  add  support  for  object-oriented  data  structures  and 
communications  between  data  management  tools.  Computer  Aided  Software 
Engineering  (CASE)  tool  proponents  are  lobbying  for  this  revision. 

e.  IRDS  does  not  support  information  communications  among  data  management 
tools. 

f.  IRDS  conformance  tests  do  not  exist,  although  they  arc  being  developed. 

g.  While  DOD  8320.1-M-l  Data  Element  Standardization  Procedures,  January  1993, 
provides  procedures  for  the  approval  and  maintenance  of  data  elements.  The 
standard  governing  the  design,  definition,  and  naming  rules  for  data  elements 
comes  from  Integration  Definition  for  I. ’formation  Modeling  (IDEF1X),  Corporate 
Information  Management  Process  Improvement  Methodology  for  DOD  Functional 
Managers  (1992).  This  has  been  adopted  as  FIPS  184. 

h.  There  are  no  implementations. 

3.4.3.1.4  Portability  caveats.  The  ANSI  and  ISO  services  interface  standards  have  diverged  and 
are  not  compatible.  All  attempts  to  converge  these  standards  have  failed  because  the  ANSI  and 
ISO  IRDS  specifiers  have  different  data  dictionary  interests.  As  a  result,  the  ISO  model  is  geared 
toward  developing  an  underlying  interface  between  the  dictionary  and  the  DBMS.  U.S.  Federal 
agencies,  the  NIST,  and  ANSI  focus  on  user  interfaces. 

One  example  of  how  ANSI  and  ISO  IRDS  diverge  is  concerned  with  whether  or  not  relationships 
are  permitted  to  have  attributes.  ISO  says  no,  on  the  grounds  that  its  simpler  model,  without 
attributes,  is  more  easily  integrated  with  SQL  tables.  ANSI  says  yes,  claiming  that  even  though  a 
model  permitting  attributes  is  more  complex  and  difficult  to  use,  it  provides  greater  flexibility  for 
more  IRDS  users.  People  using  IRDS  for  system  planning  processes,  for  example,  might  need  to 
store  certain  items  in  the  dictionary  that  would  not  necessarily  be  applicable  for  interfacing  with 
DBMSs. 
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3.4.3.1.5  Related  standards.  The  following  standards  are  related  to  data  dictionaries  or  data 
dictionary  standards: 

a.  International  Telecommunications  Unim  -  Telecommunications  Standards  Sector 
(TTU-T)  (formerly  International  Telegraph  and  Telephone  Consultative  Committee 
(CCl  l'l  ))/ISO  X.500:  Directory  Services 

b.  Standard  Textual  Language  (STL):  IEEE  1 175  (particularly  for  use  with  CASE 
tools) 

c.  Many  CASE  tools,  because  the  IRDS  acts  as  a  focus  for  sharing  data  and  metadata 
and  can  be  applied  to  them. 

d.  NIST  FIPS  183:  IDEFO 

e.  NTSTFIPS  184:  IDEF1X 

f.  Data  element  standards  in  the  data  dictionary  BSA,  above. 

3.4.3.1.6  Recommendations.  IRDS,  FIPS  156,  is  recommended.  Most  computer  vendors  laim 
that  they  are  committed  to  IRDS,  but  few  have  it  now.  If  specific  IRDS  documents  are  not 
specified  explicitly  in  a  procurement,  vendors  most  likely  will  propose  products  that  are  not 
compatible  with  IRDS. 

If  a  procurement  is  targeted  at  a  traditional  database  environment  and  a  simpler- to-use  IRDS  is 
desirable,  consider  the  ISO  specification.  If  other  environments  are  at  stake  and  attributes  on 
relationships,  or  many-to-many  relationships  are  needed  to  represent  the  relationships  between 
hardware  and  programs,  as  well  as  between  programs  and  data,  then  choose  FIPS  156  IRDS  and 
use  ANSI  IRDS  wherever  FIPS  156  has  not  specified  certain  capabilities.  Whether  the  choice  is 
for  ISO,  ANSI,  or  FIPS  IRDS,  be  prepared  to  lock  yourself  in  for  other  procurement,  rather  than 
mixing  ISO  and  ANSI  IRDS  because  of  the  incompatibilities. 


April  7,  1997 


3.4-26 


Version  3.1 


Information  Technology  Standards  Guidance 


Data  Management  Sorvioa 


3.4 32  Distributed  directory  services.  (This  BSA  appears  in  part  4,  part  9,  and  part  1 1.)  A 
directory  or  naming  service  provides  a  standardized  naming  scheme,  a  standardized  interface  with 
the  naming  facilities,  and  the  ability  for  the  interface  to  provide  transparent  access  to  a  variety  of 
naming  schemes  and  mechanisms  (e.g.,  DOEl 

Directory  service  applications  convert  a  name  into  a  physical  address  on  a  network,  providing 
logical  to  physical  conversion.  Names  can  be  user  names,  computers,  printers,  servers,  or  files. 
This  enables  users  to  find  these  resources  without  knowing  their  locations.  The  transmitting 
station  sends  a  name  to  the  server  confining  the  naming  service  software,  which  sends  back  the 
actual  address  of  the  user  or  resource. 

3.4.3.2.1  Standard.  Table  3.4-1A  presents  standards  for  distributed  directory  services. 


TABLE  3.4-16  Distributed  directory  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

K-ference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Directory 
(Globe!  end  Cell)  Service 

DCE  1.1 
Directory:  1994 

Mandated 

(Approved) 

n*c 

ISO 

Open  Systems  Inlcroonnection-Seuion  Service  Definition 

8326:1987 

Informational 

(Approved) 

[PC 

ISO 

Open  Systems  Interconnectson-Cmnection-Orieoted 
Session  Protocol 

8327:1987 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection- Basic  Connection  Oriented 
Presentation  Service  Definition 

8822:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Connecrion-Orienled 
Presentation  Protocol 

8823:1988 

Informational 

(Approved) 

[PC 

rru-T 

The  Directory:  Models  (X-ref:  ISO  9594-2) 

X.501 (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Authentication  Framework  (X-ref:  ISO 
9594-8) 

X.509,  Veraion  3: 
1993 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Abstract  Service  Definition  (X-ref:  ISO 
9594-3) 

X.511 (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
rcf:  ISO  9594-4) 

X.518:  1993 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Protocol  Specification  (X-ref:  ISO  9594-5) 

X.519  (1993) 

Informational 

(Approved) 

IK' 

ITU-T 

The  Directory:  Selected  Attributes  Types  (X-ref:  ISO 
9594-6) 

X.520  (1993) 

Informational 

(Approved) 

IK 

ITIJ-T 

The  Directory:  Selected  Object  ('lasses  (X-ref:  ISO  9594- 

7) 

X.521  (1993) 

Informational 

(Approved) 

IK 

ITU-T 

The  Directory:  Replication  (X-ref:  ISO  9594-9) 

X.525  (1993) 

Informational  [ 
(Approved)  | 

CPC 

X/Opa» 

Federated  Naming:  The  XFN  Specification 

C403  (7/95) 

Informational  0 
(Approved) 

NK 

IEEE 

Directory  service s/Name  space  API 

1224.2:1993 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

■BiSEBl 

GPC 

DOD 

Domain  Name  Service  Profile  (Ref  tree  cm  LAB  STD  13 
(RFC  1034, 1035)) 

MDL-STD-2045- 

17505:1994 

Informational 

(Approved) 

3.43.22  Alternative  specification.  There  are  no  alternative  specifications  available. 
3.4.323  Standard  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.4.3.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.4.3.2.5  Related  standards.  There  are  no  related  standards. 

3.4.3.2.6  Recommendations.  OSF  DCE  directory  services  are  recommended  for  DCE 
applications.  For  more  information  on  non-DCE  directory  services,  see  the  Host  Application 
Support  BSA  in  part  7,  Communication  Services. 
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3.4 33  Universal  syntax.  With  the  creation  of  a  DOD  Data  Element  Dictionary,  an  opportunity 
exists  to  create  a  universal  syntax  for  the  exchange  of  those  data  elements.  This  syntax  will 
address  the  entire  set  of  DOD  information  exchange  requirements  without  regard  to  its  current 
form.  It  would  meld  such  diverse  formatting  approaches  as  the  Tactical  Digital  Information  Link 
(TADDL),  United  States  Message  Text  Format  (USMTF),  and  Electronic  Document  Interchange 
(EDI). 

3.4.3.3.I  Standards.  Table  3.4-17  presents  universal  syntax  standards. 


TABLE  3,4-17  Universal  syntax  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi^i 

N/A 

N.A. 

Nooe 

N.A. 

InfoimatioaaJ 

(N.A.) 

3.4.3 3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.4.3.3J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.4.3.3.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3.4.3.3.5  Related  standards.  No  standards  are  related  to  universal  syntax  standards. 

3.4.3.3.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.4.3.4  Data  repository.  A  repository  provides  a  place  and  method  to  store  metadata.  It 
generally  is  broader  and  supports  more  kinds  of  data  than  a  data  dictionary. 

3.43.4.1  Standards.  Table  3.4-18  presents  data  repository  standards. 


TABLE  3.4-18  Data  repository  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

NPQTPC 

ANSI/ISO 

Information  Resources  Dictionary  System  2  (IRDS  2) 
(Repository  standard  revision  will  indude  an  interface  with 
CASE  unit) 

JTC 1/21. 06.04, 5; 

ANSI  X3H4 
Project  0754-D  (or 
DT7) 

Infoiuiariooai 

(Formative) 

CPC 

Various 

Various  groups  of  contractors  working  in  cooperation  with 
the  US  Navy  arid  Air  Force 

ProSLCSE,  STARS 

ItifoimarionaJ 

(Formative) 

3.43.4.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.3.43  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.43.4.4  Portability  caveats.  The  following  portability  problems  have  been  identified: 

a.  There  is  a  substantial  overlap,  and  possible  conflict,  between  the  Portable  Common 
Tool  Environment  (PCTE)  and  the  ISO  10728  (1RDS)  for  data  dictionary 
interfaces. 

b.  There  is  a  high  portability  risk  associated  with  repositories  because  no  standards 
exist 

3.43.4.5  Related  standards.  The  following  standards  are  related  to  data  repositories  or  data 
repository  standards: 

a.  ISO  10027: 1990:  IRDS  Framework.  Current  IRDS  standards  are  covered  only  in 
the  data  dictionary  sections  because  they  are  limited  in  their  ability  to  handle 
metadata.  However,  IRDS  work  is  underway  to  change  the  IRDS  standards  into  a 
full  fledged  repository  that  can  handle  a  variety  of  types  of  metadata. 

b.  ANSI  X3.138  1988:  IRDS  Command  Language  and  Panel  Interface 

c.  ANSI  X3. 195-1991:  IRDS  Export/Import  File  Format 

d.  ANSI  X3. 185-1992:  IRDS  Services  Interface 

e.  NIST  FIPS  156:  IRDS  Base  Document:  Requirements,  and  Command  Language 
and  Panel  Interface 
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f.  ISO  Draft  Proposed  (DP)  8800- 1 :  IRDS  Command  Language  and  Panel  Interface 

g.  ISO  DIS  1072C  -X:  IRDS  Services  Interface  Module  for  C  Language  Binding 

h.  All  the  SQL  standards  (e.g.,  ISO  9075:1992  SQL;  ANSI  X3. 135- 1989  SQL; 

ANSI  X3. 168- 1989;  Embedded  SQL;  FIPS  127-2;  FIPS  193) 

L  Emerging  standards  for  PCTE 

j.  Object  Management  Group's  (OMG)  Common  Object  Request  Broker 
Architecture  (CORBA)  specification 

3.4.3.4.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.4.4  Distributed  data.  These  services  support  applications  that  use  a  partitioned  database 
acting  like  a  single  coherent  database. 

3.4.4.1  Remote  data  access.  (This  BSA  appears  in  part  4  and  part  1 1.)  RDA  specifications  are 
extensions  of  a  data  access  (RDA)  language  to  allow  remote  access  to  a  database  in  a  client- 
server  environment  RDA  refers  to  the  interfaces,  protocols,  and  formats  needed  to  allow  remote 
database  access  in  a  client-server  environment  where  the  databases  may  be  heterogeneous  and 
from  multiple  vendors. 

3.4.4.1.1  Standards.  Table  3.4-19  presents  standards  for  remote  data  acc  as. 


TABLE  3.4-19  Remote  data  access  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

IPC 

ISO/IEC 

OSI  Remote  Databaae  Acceti  (RDA),  Pert  li  Generic 
Model,  Servioo  *od  Protocol 

9579-1:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Remote  Databaie  Acceu,  Part  2:  SQL  Specialization 

9579-2:1993 

Adopted 

(Approved) 

CPC 

X/Op« 

Data  Management:  SQL  Remote  Database  Acceti 

C307  (8/93) 

Infotmadonal 

(Approved) 

CPC 

X/Op«i 

Data  Management:  SQL  Call  Level  Interface  (CLI) 

C451  (4/95) 
(Supersedes  P303) 

Informational 

(Approved) 

CPC 

SAO 

Databate  Language  SQL,  Acceti  Form  alt  &  Protocols 
(PAP)  Specification:  1991  (Based  on  SQL) 

SQL  Access  FAP 
Spec*:  1991 

Informational 

(Approved) 

CPC 

SAG 

Database  language  SQL  Call  Level  Interface  (CLI) 

SQL-89 

Information*! 

(Approved) 

3.4.4.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.4.1.3  Standards  deficiencies.  RDA  specifies  the  service  and  protocol  between  only  a  single 
client  and  server.  This  is  one  reason  that  caused  the  formation  of  the  SAG  to  put  more  distributed 
functionality  into  RDA.  RDA  does  not  consider  multiple  connections  and,  therefore,  does  not 
specify  distributed  database  access.  APIs  and  Ada  bindings  to  the  RDA  standards  are  not  defined. 

RDA  is  aligned  closely  with  the  SQL-2  Entry  Level.  However,  the  integrity  enhancement  is 
optional.  Also,  RDA  is  not  aligned  currently  with  the  FIPS  127-2  Transition  Level,  which  the 
NIST  considers  very  important  for  SQL  use. 

The  ISO  RDA  and  CLI  are  only  a  subset  of  the  SAG's  RDA  and  CLI. 

3.4.4.1.4  Portability  caveats.  RDA's  use  of  ISO  Remute  Operations  Service  Elements  (ROSE) 
hinders  precision,  adds  needlessly  to  the  text  and  Abstract  Syntax  Notation  (ASN).  1 ,  and 
incorporates  assumptions  that  limit  the  usefulness  of  RDA.  Furthermore,  an  implementation 
conforming  to  ISO  9545  (the  OSI  standard  that  refines  the  basic  OS1  Reference  Model  to  provide 
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a  framework  for  coordinating  the  development  of  existing  and  future  application  layer  standards) 
could  not  use  ROSE,  since  they  both  claim  to  be  application  service  elements. 

RDA's  optional  integrity  enhancement  and  the  lack  of  alignment  with  the  FIPS  127-2  Transition 
Level  can  result  in  differences  among  systems  compliant  with  RDA  that  impede  portability  and 
interoperability. 

3.4.4. 1.5  Related  standards.  The  following  standards  are  related  to  remote  data  ac  'ess  or 
remote  data  access  standards: 

a.  ISC  9072:  ROSE 

b.  ISO  9075: 1 992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  1 27-2: 1 993) 

c.  ISO  10026-1..3:  Distributed  Transaction  Processing  Mode),  Service,  &  Protocol 

d.  ANSI  X3.135-1989:  SQL 

e.  ANSI  X3.168-1989:  Embedded  SQL 

f.  X/Open  C193:  Distributed  TP:  The  XA  Specification 

3.4.4.1.6  Recommendations.  The  first  choice  for  a  standard  would  be  RDA,  ISO  9579,  and 
RDA:  SQL  Specialization,  ISO  9579-2,  unless  the  additional  functionalities  provided  by  the  SAG 
are  needed. 

Where  RDA  lacks  desired  capabilities  for  a  procurement,  consider  SQL  Access  Formats  and 
Protocols  Specifications  or  the  X/Open  RDA.  The  SAG  and  X/Open  are  tracking  the  RDA 
standard  and  both  support  RDA  extensions  that  are  being  adopted  by  the  emerging  RDA 
standard.  Consider  the  X/Open  specified  ASN.  1  replacement  module  that  eliminates  the  use  of 
ROSE. 
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3.4.4 2  Database  recovery.  (This  BSA  appears  in  both  part  4  and  part  9.)  Database  recovery 
refers  to  the  ability  to  detect  a  failure  in  a  system,  recover  from  failure,  and  permit  a  slave  copy  to 
become  a  master  copy,  assuring  data  integrity  ana  consistency. 

3.4.4.2.1  Standards.  Table  3.4-20  presents  standards  for  database  recovery. 


TABLE  3.4-20  Database  recovery  standards 


Standard 

Sponsor 

Standard 

Standard 

Type 

Reference 

HH 

[PC 

ISO/TEC 

OS I  Service  Definition  for  the  Commitment,  Concurrency, 
and  Recovery  (CCR)  Service  Element 

98<X  1990 

Informational 

(Approved) 

IPC 

1SO/IEC 

OS  I  Protocol  Specification  for  the  Commitment, 
Concurrency,  and  Recovery  (CCR)  Service  Element 

9805:1990 

Informational 

(Approved) 

3.4.4.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.4.4.2.3  Standards  deficiencies.  Deficiencies  in  database  recovery  standards  are  unknown. 

3.4.4.2.4  Portability  caveats.  At  present,  CCR  is  not  widely  implemented,  although  most 
vendors  intend  to  implement  it  Therefore,  one  should  make  no  assumptions  about  the  degree  of 
portability  and  interoperability  existing  for  any  database  recovery  utilities. 

3.4.4.2.5  Related  standards.  The  following  standards  are  related  to  database  recovery  or 
database  recovery  standards: 

a.  ISO/IKC  10026  Parts  1, 2,  and  3:  Distributed  Transaction  Processing  (DTP) 
protocol 

b.  X/Open  XA  Interface  specification,  which  includes  CCR's  two-phase  commitment 

3.4.4.2.6  Recommendations.  If  CCR  is  desired  (and  it  is  necessary  for  multivendor,  distributed 
database  and  distributed  transaction  processing),  it  must  be  referenced  specifically  in  procurement 
specifications.  Otherwise,  vendors  probably  will  propose  products  that  do  not  meet  this 
specification. 

For  the  greatest  portability,  design  applications  as  if  CCR  were  not  present. 
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3A.4.3  Distributed  database.  Distributed  database  services  allow  partitioning  (including 
physical  partitioning)  and,  possibly,  partial  replication  of  a  database  so  that  the  partitioned 
database,  which  is  distributed  at  different  sites,  still  behaves  like  a  single,  coherent  database.  If 
redundant  data  are  stored  in  separate  databases  to  meet  performance  requirements,  updates  to  one 
set  of  data  will  update  the  additional  sets  automatically  in  a  timely  and  controlled  manner.  A 
Client-Server  Data  Management  Model  for  Distributed  Processing,  such  as  the  Distributed 
Computing  Environment  (DCE),  also  is  required. 

3.4.4.3.I  Standards.  Table  3.4-21  presents  standards  for  distributed  databases. 


TABLE  3.4-21  Distributed  database  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

OSI  Remote  Database  Access  (RDA):  Some  ditfributed 
database  capabilities  in  future  RDA  revisions 

9579  (future) 

Informational 

(Formative) 

NPC/DPC 

ANSI/ISO 

Information  Resources  Dictionary  Syrian  2  (IRDS2) 
(Repository  standard  revision  will  indutk  an  interface  with 
CASE  tool*) 

JTC1/21 .06.04,5; 

ANSI  X3H4 
Project  0754- D  (or 
DT7) 

Informational 

(Formative) 

X4.4.3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.4.3.3  Standards  deficiencies.  No  standards  exist  to  ensure  data  integrity  across  data  residing 
at  multiple  locations.  The  term  distributed  databases  does  not  have  a  standard  definition. 
Databases  ranging  from  traditional  databases  that  are  accessed  from  distributed  locations  to 
databases  that  support  distributed  query  and  distributed  query  and  update,  are  called  distributed 
databases. 

3.4.4.J.4  Portability  caveats.  Vendors'  SQLs  are  not  exactly  the  same.  Distributing  such  not- 
quite-the-same  databases  can  cause  portability  problems.  If  the  meaning  and  identity  of  the  data 
administered  at  different  sites  and  on  different  systems  are  different,  users  will  lose  portability. 
Worse,  they  will  receive  wrong  answers  to  their  queries  and  will  not  be  able  to  recognize  that  the 
answers  are  wrong. 

3.4.4.3.S  Related  standards.  The  following  standards  are  related  to  distributed  databases  or 
distributed  database  standards: 

a.  ISO  9075: 1 992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  1 27-2: 1 993) 

b.  ISO  9804/9805:  CCR 

c.  ISO  10026-1,2,3:  Distributed  Transaction  Processing  Model,  Service,  and 
Protocol 

d.  X/Open  C193  (1992):  Distributed  TP:  The  XA  Specification 
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3.4.4.3.6  Recommendations.  There  are  no  standards  to  recommend.  Distributed  database 
products  must  support  ISO  9804/9805  CCR  (for  the  two-phase  commit  specification). 


April  7,  1997 


3.4-36 


Version  3.1 


Information  Technology  Standards  Guidance 


Data  Management  Services 


3.4 £  Object  database.  An  object-oriented  database  is  one  that  holds  abstract  data  types 
(objects).  It  can  store  objects  directly  from  an  object-oriented  programming  language.  Because 
any  type  of  data  can  be  stored  (the  rules  for  processing  the  data  are  part  of  an  object),  the  object 
database  promises  fully  integrated  databases  that  will  hold  data,  text,  pictures  and  voice, 
essentially  an  endless  variety  of  ever-changing  formats.  It  is  capable  of  handling  complex  queries 
about  objects  that  would  be  difficult  in  relational  database  programs. 

3.4.5. 1  Object-oriented  database  management.  (This  BSA  appears  in  both  Part  4  and  Part  9.) 
Standards  for  object-oriented  database  management  provide  facilities  and  interfaces  to  manage 
object  databases  (databases  that  store,  manipulate,  and  retrieve  data  represented  as  objects). 

3.4.5. 1.1  Standards.  Table  3.4-22  presents  standards  for  object-oriented  database  management. 


TABLE  3.4-22  Object-oriented  database  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

ODMG 

Object  Database  Management  Group  (ODMG)  •  93 

ODMG -93,  Release 
1.1 

Informational 

(Approved) 

CPC 

ODMG 

Object  Database  Management  Group  (ODMG)  9x 

ODMG-9X 

Emerging 

(Formative) 

NPC 

ANSI 

X3  Database  System  Study  Group  (DBSSQ) 

X3  Study 

Informational 

(Formative) 

CPC 

OMG 

Preliminary  wo*  on  object- oriented  database  management 

jftBi 

Informational 

(Formative) 

3.4.5.1.2  Alternative  specifications.  Microsoft's  Object  Database  Connectivity  (OBDC)  API 
specification  for  MS-Windows  applications  is  also  available. 

3.4.5. L3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard,  but  the  Microsoft  specification  has  insufficient  drivers 
available. 

3.4.5.1.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist,  and 
many  Microsoft  PC  products  do  not  comply  with  most  Unix-  and  Portable  Operating  System 
Interfaces  for  Computers  (POSIX)-based  systems. 

3.4.5.1.5  Related  standards.  No  standards  are  related  to  object-oriented  database  management 
sts  'dards. 

3.4.5.1.6  Recommendations.  There  is  no  recommendation  at  this  time. 
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3.4.6  Transaction  processing.  Orders,  purchases,  changes,  additions,  and  deletions  are  examples 
of  transactions  recorded  in  a  business  information  environment  Queries  and  other  requests  are 
also  transactions  to  the  computer,  but  usually  are  just  acted  upon  and  not  recorded  in  the  system. 
A  transaction  is  a  completed  event  that  can  be  assembled  in  chronological  sequence  for  an  audit 
trail.  Transaction  processing  systems,  also  called  on-line  or  real  time  systems,  update  master  files 
as  soon  as  they  are  entered  at  terminals  or  arrive  over  communications  lines.  Contrast  this  with 
batch  processing,  which  stores  transactions  and  updates  the  necessary  files  at  a  later  date. 

3.4.6. 1  Protocol  for  interoperability  in  heterogeneous  transaction  processing  systems.  These 
specifications  support  Transaction  Processing  (TP)  systems  containing  components  from  diverse 
sources  and  between  dissimilar  transaction  processing  systems. 

3.4.6.1.1  Standards.  Table  3.4-23  presents  standards  for  protocols  for  interoperability  in 
heterogeneous  transaction  processing  systems. 

TABLE  3.4-23  Protocol  for  interoperability  in  heterogeneous  transaction  processing 


systems  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

OSI  Diitributed  Traiuacdon  Procuring  (DTP)  •  Part  1: 
OSITP  Model 

10026-1:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Distributed  Tram  Action  Procuring  (DTP)  ■  Psrt  2: 
OSI  TP  Service 

10026-2:1996 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Diitribuied  Tranuction  Procuiing  (DTP)  •  Part  3: 
Protocol  Specification 

10026-3:1996 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Diitributed  Tranuction  Proceuing  (DTP),  Part  4: 
Protocol  Implementation  Conformance  Statement  (PICS) 
Proforma 

10026-4:1995 

Information*] 

(Approved) 

IPC 

ISO/IEC 

OSI  Dii  tribute*)  Tram  action  Proceuing  (DTP),  Part  6: 
Unitmctuied  DaiaTranifer 

10026-6:1995 

(nfomutional 

(Approved) 

IPC 

ISO/IEC 

OSI  Diitributed  Tram  act  ion  Proceuing  (DTP),  Part  5: 
Application  Context  Proforma  and  Guideline!  When  Uiing 
OSITP 

10026-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Diitributed  Tram  act  ion  Proceuing  (DTP),  Part  7: 
Menage  Queueing 

10026-7 

Informational 

(Draft) 

3.4.6.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.4.6. 1.3  Standards  deficiencies.  The  following  deficiencies  have  been  identified  in  the  available 
standards: 

a.  No  standardized  API  to  the  ISO  DTP  protocol. 

b.  No  Ada  binding  to  the  ISO  10026  services  or  protocol. 

c.  The  ISO  10026  DTP  model  does  not  address  the  overall  environment. 
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3.4.6.1.4  Portability  caveats.  Portability  problems  for  the  ISO  TP  protocol  are  unknown.  The 
IEEE  P1003. 1 1  Group  is  disbanded.  P1003. 1 1  draft  documents  and  current  work  are  being 
transferred  to  the  P1003.0  Group. 

3.4.6. 1.5  Related  standards.  The  following  standards  are  related  to  interoperability  in 
heterogeneous  TP  systems: 

a.  ISO  9041-1:  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075:1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2:1993) 

c.  ISO  9579- 1 :  RDA  (Generic  Model,  Service  and  Protocol) 

d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9594  Parts  1-8:  Directory  Services 

f.  ISO  9804/9805:  CCR 

g.  ISO  DIS  10148:  RPC 

h.  ISO  Working  Draft  (WD)  10181-1:  Security  Frameworks  in  Open  Systems:  Part 
1:  Overview 

i.  ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 
Framework 

j.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

k.  ISO  11578:  RPC 

l.  ITU-T  Recommendation  X.500:  Directory  Services 

m.  IEEE  P 1003. 1  b:  Real-Time  Extension  to  POSIX 

n.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

o.  IEEE  P1003.17:  Directory  Services  API 

p.  European  Computer  Manufacturers'  Association  (ECMA)  127:  RPC 

q.  ECMA  Technical  Report:  Support  Environment  for  Open  Distributed  Processing 
(SE-ODP) 
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r.  OSF:  DCE  RPC 

s.  X/Open  C193,  S423:  XA  and  XA+  Interfaces 

3.4.6.1.6  Recommendations.  ISO  10026,  parts  1, 2,  and  3,  is  recommended. 
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3.4.6.2  Transaction  manager- to- resource  manager  interface.  These  standards  specify  the 
interface  from  the  transaction  manager  to  the  resource  manager.  In  some  models,  only  transaction 
managers  can  communicate. 

3.4.6. 2.1  Standards.  Table  3.4-24  presents  standards  for  the  transaction  manager  to  resource 
manager  interface. 


TABLE  3.4-24  Transaction  manager-to-resource  manager  interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Distributed  TP:  The  XA  Specification 

Cl  93  (202) 

Adopted 

(Approved) 

CPC 

X/Open 

Distributed  17:  Reference  Model,  Vernon  2 

G307  (1 103) 

Informational 

(Approved) 

CPC 

X/Op<n 

Distributed  TP:  Reference  Model,  Vernon  3 

0504  (2/96) 

Informational 

(Approved) 

3.4.6 .2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6.2J  Standards  deficiencies.  No  Ada  binding  to  the  X/Open  XA  Specification  exists.  The 
XA  interfaces  do  not  address,  or  directly  accept  hash  values  for  global  transaction  identifiers. 
(Hash  value  handling  capabilities  were  addressed  in  the  preliminary  specification,  but  were 
dropped  in  the  final  specification.)  The  comparison  of  global  IDs  is  indirect  and  convoluted, 
rather  than  explicit 

3.4.6.2.4  Portability  caveats.  In  the  X/Open  distributed  transaction  processing  model,  the  major 
and  most  accepted  model  to  date,  the  transaction  manager  is  bundled  with  the  communications 
manager.  Although  this  can  enhance  transaction  communications  efficiency,  it  also  makes  it  more 
difficult  to  define  a  portable  and  interoperable  interface  with  a  multitude  of  communications 
systems,  including  legacy  systems. 

3.4.6.2.5  Related  standards.  The  following  standards  are  related  to  transaction  manager-to- 
resource  manager  interface  standards: 

a.  ISO  904 1  - 1 :  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075: 1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2:1993) 

c.  ISO  9579- 1 :  RDA  (Generic  Model,  Service  and  Protocol) 
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d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9594  Parts  1-8:  Directory  Services 

f.  ISO  9804/9805:  CCR 

g.  ISO  10026:  DTP  Model,  Services,  and  Protocol 

h.  ISO  DIS  10148:  RPC 

L  ISO  WD  10181-1:  Security  Frameworks  in  Open  Systems:  Part  1:  Overview 

j.  ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 

Framework 

k.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

L  ISO  DP  11578:  RPC 

m.  ITU-T  Recommendation  X.500:  Directory  Services 

n.  IEEE  P1003.1b:  Real-Time  Extension  to  POSIX 

o.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

p.  IEEE  P1003. 17:  Directory  Services  API 

q.  ECMA  127:  RPC 

r.  ECMA  Technical  Report:  SE-ODP 

s.  OSF:  DCE  RPC 

3.4.6.2.6  Recommendations.  Open  distributed  TP  systems  must  support  X/Open  XA  interfaces, 
because  no  other  specification  exists  for  transaction  manager-to-resource  manager  interfaces. 

Unless  the  communications  manager  is  decoupled  from  the  transaction  manager,  be  very  careful 
about  any  distributed  transaction  processing  systems  that  claim  to  provide  portability  with  legacy 
communications  systems. 
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3.4.6  3  Transaction  manager-to-communications  manager  interface.  These  standards  specify 
the  interface  from  the  transaction  manager  to  the  communications  manager.  In  some  specifications 
the  communications  manager  was  part  of  the  transaction  manager.  These  specifications  cover  the 
case  in  which  the  communications  manager  has  been  extracted  and  decoupled  from  the 
transaction  manager. 

3.4.63.1  Standards.  Table  3.4-25  presents  standards  for  the  transaction  manager  to 
communications  manager  interface. 


TABLE  3.4-25  Transaction  manager-to-communications  manager  interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

X/Open 

Distributed  TP:  The  TxRPC  Specification 

C505  (11/95) 

Adopted 

(Approved) 

CPC 

X/Open 

Distributed  TP;  The  XATMI  Specification 

C506  (11/95) 

Adopted 

(Approved) 

CPC 

X/Open 

Distributed  TP:  The  XA+  Specification,  Vernon  2  (Bated 
on  CPI-C.  Vernon  2) 

S423  (7/94) 

Adopted 

(Approved) 

CPC 

X/Oper 

Diitiibuted  TP:  TxRPC  Specification  (Bated  on  X/Opcn 
DCE  RPC  paradigm) 

P305  (7/93) 

Informational 

(Superseded) 

CPC 

X/Open 

P306  (7/93) 

Informational 

(Superseded) 

3.4.63.2  Alternative  specifications.  The  following  specification  is  also  available: 

a.  Transarc:  Encina 

3.4.6.33  Standards  deficiencies.  No  Ada  binding  is  being  developed  for  the  XA+  Interface. 

3.4.63.4  Portability  caveats.  The  XA+  Interface  is  highly  controversial  because  although 
decoupling  the  communications  manager  from  the  transaction  manager  makes  it  easier  to 
integrate  different  communications  systems  and  paradigms,  such  decoupling  can  result  in  a  loss  of 
communications  efficiency  and  performance.  Consequently  with  good  reason,  various  vendors 
may  bundle  the  communications  and  transaction  managers  together  with  the  resulting  loss  of 
portability  because  of  the  need  to  write  different  communications  interfaces. 

3.4.633  Related  standards.  The  following  standards  are  related  to  transaction  manager-to- 
communications  manager  interface: 

a.  ISO  904 1  - 1 :  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9594  Parts  1-8:  Directory  Services 

c.  ISO  9804/9805:  CCR 


April  7,  1997 


3.4-43 


Version  3.1 


Information  Technology  Standards  Guidanci 


Data  Management  Services 


d.  ISO  10026:  DTP  Model,  Services,  and  Protocol 

e.  ISO  DIS  10148:  RPC 

f.  ISO  WD  10181-1:  Security  Frameworks  in  Open  Systems:  Part  1:  Overview 

g.  ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 
Framework 

h.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

L  ISO  DP  11578:  RPC 

j.  ITU-T  Recommendation  X.500:  Directory  Services 

k.  '  P1003.1b:  Real-Time  Extension  to  POSIX 

l  lfc,^  ,  ,  Pitiy'1- r  >• .  ’hreauo  Extension  to  POSIX 

m.  IEEE  PI  (XL  i,  ectory  Services  API 

n.  ECMA  12  .  .fC 

o.  OSF:  DCE  RPC 

p.  X/Open  C193:  XA  Interface 

3.4.6.3.6  Recommendations.  If  it  is  desirable  to  decouple  the  transaction  manager  from  the 
communications  manager,  such  decoupling,  as  well  as  the  XA+  specification,  must  be  specified 
explicitly  in  procurement  specifications.  Otherwise,  vendors  probably  will  propose  products  that 
do  not  meet  this  specification.  X/Open  S423,  P306,  and  P305  are  recommended. 

For  ease  of  integration  with  legacy  communications  and  transaction  processing  systems,  be  sure 
the  communications  manager  is  decoupled  from  the  transaction  manager.  If  performance  is  an 
issue,  at  least  for  the  near  term,  require  the  communications  and  transaction  manager  to  be 
bundled  together. 
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3A.6.4  Application-to- communications  resource  manager  interface.  These  specifications 
define  the  interface  between  the  application  and  the  communications  manager,  which  is  a  type  of 
resource  manager. 

3. 4.6.4. 1  Standards.  Table  3.4-26  presents  standards  for  application  to  communications  resource 
manager  interfaces. 


TABLE  3.4-26  Application-to-communications  resource  manager  interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

h 

CPN-C 

U1 

CM  Reference  Specification 

IV  Standard* 
Strategy  White 
Paper,  Rev.  4.0 

Informational 

(Approved) 

CPC 

X/Op m 

CM  Specification 

Working  Paper* 

Informational 

(Formative) 

3.4.6.4.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Transarc:  Encina 

b.  NCR:  Top  End 

3.4.6.4  J  Standards  deficiencies.  Neither  an  Ada  nor  a  Cobol  binding  is  being  developed  for  the 
Communications  Manager  (CM)  interface,  although  the  architecture  of  the  CM  interface  is  easily 
adaptable  to  the  Ada  language. 

3.4.6.4.4  Portability  caveats.  The  CM  Interface  is  controversial  because  it  implies  that  the 
communications  manager  is  decoupled  from  the  transaction  manager.  This  is  controversial  as 
explained  further  in  the  section  on  the  XA+  interface.  For  example,  AT&T/USL's  Tuxedo  bundles 
the  transaction  manager  with  the  communications  manager.  Thus,  Tuxedo  is  not  likely  to  be 
compatible  with  the  CM  interface. 

The  number  of  vendors  committed  to  implementing  the  CM  interface  probably  will  make  it  a  de 
facto  standard  once  it  is  adopted  by  X/Open.  This  may  create  portability  problems  with  Tuxedo, 
which  is  currently  the  most  widely  used  transaction  manager. 

3.4.6.4.5  Related  standards.  The  following  standards  are  related  to  application-to- 
communications  resource  manager  interface: 

a.  ISO  904 1  ■  1 :  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9594  Parts  1-8:  Directory  Services 

c.  ISO  9804/9805:  CCR 

d.  ISO  10026:  DT?  Model,  Services,  and  Protocol 
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e.  ISO  DIS  10148:  RPC 

f.  ISO  WD  10181-1:  Security  Frameworks  in  Open  Systems:  Part  1:  Overview 

g.  ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 
Framework 

h.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

L  ISO  DP  11578:  RPC 

j.  ITU-T  Recommendation  X.500:  Directory  Services 

k.  IEEE  P1003.1b:  Real-Time  Extension  to  POSIX 
L  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

m.  IEEE  P1003. 17:  Directory  Services  API 

n.  ECMA  127:  RPC 

o.  OSF:  DCE  RPC 

p.  X/Open  C193:  XA  Interface 

q.  X/Open  S423:  XA+  Specification 

3.4.6.4.6  Recommendations.  If  it  is  desirable  to  decouple  the  transaction  manager  from  the 
communications  manager,  such  decoupling,  as  well  as  the  emerging  CM  specification,  must  be 
specified  explicitly  in  procurement  specifications.  Otherwise,  vendors  probably  will  propose 
products  that  do  not  meet  this  specification. 

For  ease  of  integration  with  legacy  communications  and  transaction  processing  systems,  be  sure 
the  communications  manager  is  decoupled  from  the  transaction  manager.  If  performance  is  an 
issue  at  least  for  the  near  term,  require  the  communications  and  transaction  manager  to  be 
bundled  together. 
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3.4.6 3  Communications  manager-to- protocol  stack  interface.  These  specifications  define  the 
interface  between  the  communications  manager  and  the  underlying  protocol  stacks.  They  allow  a 
single  communications  manager  to  interface  with  multiple,  independently  provided  protocol  stack 
implementations,  and  multiple  CMs  to  be  integrated  with  a  single  protocol  stack  implementation. 

3.4.6.5.1  Standards.  Table  3.4-27  presents  standards  for  the  communications  manager  to 
protocol  stack  interface. 


TABLE  3.4-27  Communications  manager-to-protoco!  stack  Interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

{Lifecycle) 

CPC 

X/Open 

ACSE/PreienUtion:  Traniactkm  Procuring  API  (XAP-TP) 

C409  (4/95) 

Informational 
(Approved)  1 

NPC 

tFFP. 

XAP-TP  Specification  (Baaed  on  X/Open'i  XAP-TP 
Specification) 

Number  not  yet 
auigned 

Informational 

(Draft) 

3.4.6 .5.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.4.6.S  J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.4.6.5.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  have  been 
completed. 

3.4.6.S2S  Related  standards.  The  following  standards  are  related  to  communications  manager-to- 
protocol  stack  interface  standards: 

a.  ISO  904 1  - 1 :  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9594  Parts  1-8:  Directory  Services 

c.  ISO  DIS  10148:  RPC 

d.  ISO  WD  10181-1:  Security  Frameworks  in  Open  Systems:  Part  1:  Overview 

e.  ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 
Framework 

f.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

g.  ISO  DP  11578:  RPC 

h.  ITU-T  Recommendation  X.500:  Directory  Services 
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L  IEEE  P1003. lb:  Real-Time  Extension  to  POSIX 
j.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

Ic.  IEEE  P1003. 17:  Directory  Services  API 

L  ECMA  127:  RPC 

m.  OSF:  DCE  RPC 

.7  4. 6.5.6  Recommendations.  The  X/Open  ACS  ^Presentation  -  Transaction  Processing  API 
(XAP-TP)  specification  must  be  referenced  specifically  in  procurement  specifications,  and  a 
requirement  to  move  to  the  XAP-TP  specification  as  soon  as  it  is  adopted  by  X/Open  also  must 
be  stated  there  specifically.  Otherwise,  vendors  probably  will  propose  products  that  do  not  meet 
this  specification. 

To  maximize  interoperability  and  portability,  the  emerging  XAP-TP  interface  should  be  used 
when  it  is  adopted  by  X/Open  for  the  interface  between  the  communications  manager  and  the 
protocol  stack(s)  being  used. 
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3.4.6.6  Transaction  demarcation.  These  specifications  define  the  interface  between  the 
transaction  manager  and  the  application,  taking  transaction  demarcation  information  from  the 
application  and  delimiting  the  transaction  to  the  resource  manager. 

3. 4. 6.6.1  Standards.  Table  3.4-29  presents  standards  for  transaction  demarcation. 


TABLE  3.4-28  Transaction  demarcation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

XA)pen 

Distributed  TP:  The  TX  (Transaction  Demarcation) 
Specification 

C504  (4/95) 

Adopted 

(Approved) 

CPC 

XJOpcc 

Distributed  TP:  The  XA  Specification 

C193  (2/92) 

Informational 

(Approved) 

CPC 

X/Open 

Structured  Transaction  Definition  Language  (STDL) 

P336  (12/95) 

Informational 

(Approved) 

CPC 

MIA  Consortia 

Standardized  Transaction  Definition  Language  (STDL) 

na 

Informational 

(Approved) 

CPN-C 

UI 

ATMI  (Application  to  Transition  Manager  Interface) 
Specification 

Tims.  Monitor  I/P 
Spec.  Ver.  1.0:1991 

Informational 

(Approved) 

CPC 

X/Open 

Distributed  TP:  The  TX  (Transaction  Demarcation) 
Specification 

P209  (11/92) 

Inform  alio, ttl 
(Superseded) 

3.4.6.6.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6.6J  Standards  deficiencies.  The  TX  specification  does  not  support  traditional  transaction 
monitor  functions  such  as  screen  management  and  terminal  management. 

3.4.6.6.4  Portability  caveats.  Unlike  the  XA  interface,  which  had  no  installed  base  to  displace, 
every  transaction  process’  g  system  has  its  own  interface  between  the  application  and  the 
transaction  manager  that  celimits  a  transaction.  Therefore  gains  in  multivendor  portability  for  new 
systems  are  offset  by  a  decrease  in  portability  across  legacy  TP  systems. 

Without  a  standard  API  between  transaction  processing  applications  and  transaction  managers, 
portable  formal  and  do  facto  standardized  Fourth  Generation  Languages  (4GLs)  are  unlikely  to  be 
developed.  Furthermore,  vendors  will  develop  and  port  their  4GLs  only  to  the  most  popular,  best¬ 
selling  transaction  processing  platforms. 

The  IEEE  P1003.1 1  group,  which  was  developing  a  profile  for  transaction  processing 
environments,  has  been  disbanded.  The  P1003.1 1  draft  documents  and  current  work  are  being 
transferred  to  the  PI 003.0  group. 
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3.4. 6. 6.5  Related  standards.  The  following  standards  are  related  to  transaction  demarcation  or 
transaction  demarcation  standards: 

a.  ISO  9579- 1 :  RDA  (Generic,  Model,  Service  and  Protocol) 

b.  ISO  9579-2:  RDA  (SQL  Specialization) 

c.  ISO  9594  Parts  1-8:  Directory  Services 

d.  ISO  10026-1,  -2,  -3:  DTP  Protocol 

e.  ISO  DIS  10148:  RPC 

f.  ISO  WD  10181-1,  -2,  -3:  Security  Frameworks  in  Open  Systems,  Part  1: 
Overview,  Part  2:  Authentication  Framework,  Part  3:  Access  Control  Framework 

g.  ISO  11578:  RPC 

h.  IEEE  P1003.1b:  Real  time  Extension  to  POSIX 

i.  IEEE  P1003. 1c:  Threads  Extension  to  POSIX 

j.  IEEE  PI 003. 17:  Directory  Services  API 

k.  ECMA  TR/SE-ODP 

l.  ECMA  TR/29:  Open  Systems  Interconnection  -  Distributed  Interactive  Processing 
Environment 

m.  ECMA  127:  RPC 

n.  OSF:  DCE  RPC 

o.  X/Open  S423:  XA+  Interfaces 

3.4.6.6.6  Recommendations.  The  TX  specification  is  recommended  and  must  be  referenced 
specifically  in  procurement  specifications.  Otherwise,  vendors  probably  will  propose  products  that 
do  not  meet  this  specification. 

Plan  for  at  least  two  interfaces:  the  TX  interface  for  new  multivendor,  distributed  systems  and  the 
legacy  TP  interface  for  existing  TP  systems.  The  TX  Specification  and  XA  Specification  are 
complementary  specifications  the  MIA  consortia's  STDL  (Standardized  Transaction  Definition 
Language)  However,  may  provide  great  acceptance  by  certain  large  vendors. 
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3.4.6.7  Transaction  monitoring  services  and  interfaces.  Transaction  management  systems 
monitor  network  transaction  flow  and  workload  balance. 

3.4.6.7.1  Standards.  Table  3.4-29  presents  standards  for  transaction  monitoring  services  and 
interfaces. 


TABLE  3.4-29  Transaction  monitoring  services  and  interfaces  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

Node 

N.A. 

Informal  ocul 
(N.A.) 

3.4.6.7.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3  4.6.7J  Standards  deficiencies.  A  requirement  has  been  identified  for  a  standardized 
transaction  management  system  to  manage  network  transaction  flow  and  workload  balancing. 

3.4.6.7.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3. 4. 6. 7.5  Related  standards.  The  following  standards  are  related  to  transaction  monitoring  or 
transaction  monitoring  standards: 

a.  ISO  9041-1:  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075: 1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2: 1993) 

c.  ISO  9579-1:  RDA  (Generic  Model,  Service  and  Protocol) 

d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9804/9805:  CCR 

f.  ISO  DIS  10148:  RPC 

g.  ISO  WD  10181-1,-2,-3:  Security  Frameworks  in  Open  Systems:  Part  1 : 
Overview;  Part  2  Authentication  Framework;  Part  3:  Access  Control  Framework 

h.  ISO  11578:  RPC 

i.  IEEE  P1003. 1  b:  Real-Time  Extension  to  POS1X 
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j.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

k.  ECMA  127:  RPC 

L  OSF:  DCE  RPC 

m.  X/Open  C193:  XA  Interfaces 

3.4.6.7.6  Recommendations.  USL's  Tuxedo  and  Transarc's  Encina  show  signs  of  becoming  de 
facto  standards.  Tuxedo  is  the  only  DTP  system  that  is  not  beginning  to  emerge  and  has  field 
experience  (e.g..  Version  4.X  is  offered,  rather  than  Version  1  .X).  Tuxedo  also  formed  the  base 
document  for  X/Opcn's  XA  and  TX  interfaces.  On  the  other  hand,  Encina  is  designed  to  be 
integrated  more  easily  integrated  with  legacy  TP  systems.  Therefore,  Encina  is  central  to  the  TP 
directions  and  strategies  of  several  major  TP  vendors,  however,  there  are  no  standards  to 
recommend. 
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3.4.0.8  Terminal  communications.  These  standards  provide  support  for  terminal 
communications  in  a  transaction  processing  system. 

3. 4.6. 8.1  Standards.  Table  3.4-30  presents  standards  for  terminal  communications. 


TABLE  3.4-30  Terminal  communications  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hj 

N/A 

N.A. 

None 

N.A. 

In/ormatkxui 

(N.A.) 

3.4.6.S.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6.8J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown. 

3.4.6.8.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist 
The  IEEE  P1003. 1 1  group,  which  was  developing  a  profile  for  transaction  processing 
environments,  has  been  disbanded.  The  P 1 003. 1 1  draft  documents  and  current  work  are  being 
transferred  to  the  PI 003.0  group. 

3.4.6.8.5  Related  standards.  The  following  standards  are  related  to  terminal  communications  or 
terminal  communications  standards: 

a.  ISO  9041-1:  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075: 1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2:1993) 

c.  ISO  9579-1:  RDA  (Generic  Model,  Service  and  Protocol) 

d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9594  Parts  1-8:  Directory  Services 

f.  ISO  9804/9805:  CCR 

g.  ISO  DIS  10148:  RPC 

h.  ISO  WD  10181-1:  Security  Frameworks  in  Open  Systems:  Part  1:  Overview 
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ISO  DIS  10181-2:  Security  Frameworks  in  Open  Systems:  Part  2:  Authentication 
Framework 


j.  ISO  DIS  10181-3:  Security  Frameworks  in  Open  Systems:  Part  3:  Access  Control 
Framework 

k.  ISO  11578:  RPC 

L  ITU-T  Recommendation  X.500 

m.  DtsEE  P1003.  lb:  Real-Time  Extension  to  POSIX 

n.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

o.  IEEE  P1C03. 17:  Directory  Services  API 

p.  ECMA  TR/SE-ODP 

q.  ECMA  TR/29:  Open  Systems  Interconnection  -  Distributed  Interactive  Processing 
Environment 

r.  ECMA  127:  RPC 

s.  OSF:  DCE  RPC 

t.  X/Open  Cl 93:  XA  Interfaces 

3.4.6.8.6  Recommendations.  USL's  Tuxedo  and  Transarc's  Encina  have  interfaces  in  this  area. 
Both  show  signs  of  becoming  de  facto  standards.  Tuxedo  also  formed  the  base  document  for 
X/Open's  XA  and  TX  interfaces.  On  the  other  hand,  Encina  is  designed  to  be  integrated  more 
easily  with  legacy  TP  systems  including  IBM  mainframes.  Therefore,  Encina  is  central  to  the  TP 
directions  and  strategies  of  several  major  TP  vendors.  There  are  no  standards  to  recommend. 
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3.4.6.9  Transaction  program  scheduling.  These  standards  provide  scheduling  support  for 
transaction  processing. 

3.4.6.9.1  Standards.  Table  3.4-31  presents  standards  for  transaction  program  scheduling. 


TABLE  3.4-31  Transaction  program  scheduling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

lull 

N/A 

N.A. 

Nooe 

N.A. 

Informational 

(N.A.) 

3.4.6.9.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6.9J  Standards  deficiencies.  Deficiencies  in  the  emerging  IEEE  standard  are  unknown. 

3.4.6.9.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist 
The  IEEE  P1003.1 1  group,  which  was  developing  a  profile  for  transaction  processing 
environments,  has  been  disbanded.  The  P1003.1 1  draft  documents  and  current  work  are  being 
transferred  to  the  P1003.0  group. 

3.4.6.9.5  Related  standards.  The  following  standards  are  related  to  transaction  program 
scheduling  or  transaction  program  scheduling  standards: 

a.  ISO  9041-1:  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075:  1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2:  1993) 

c.  IEEE  P1003.1c:  Threads  Extension  to  POSIX 

3.4.6.9.6  Recommendations.  There  are  no  standards  to  rei  mend. 
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3.4.6.10  Transaction  message  queuing.  These  standards  provide  specifications  for  a  message 
queue  in  a  transaction  processing  environment 

3.4.6.10.1  Standards.  Table  3.4-32  presents  standards  for  transaction  message  queuing. 


TABLE  3.4-32  Transaction  message  queuing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.4.6.10.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6. 10  J  Standards  deficiencies.  Deficiencies  in  the  emerging  IEEE  standard  are  unknown. 

3.4.6.10.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 
The  IEEE  P1003.1 1  group,  which  was  developing  a  profile  for  transaction  processing 
environments,  has  been  disbanded.  The  P 1003. 1 1  draft  documents  and  current  work  are  being 
transferred  to  the  P1003.0  group. 

3.4.6.10.5  Related  standards.  The  following  standards  are  related  to  transaction  message 
queuing  or  transaction  message  queuing  standards: 

a.  ISO  9041-1:  Basic  Class  Virtual  Te'  -  -r  'Protocol  Specification 

b.  ISO  9075: 1992:  SQL  3rd  edition 

c.  IEEE  P1003.1b:  Real-Time  Extension  to  POSIX 

d.  IEEE  P1003.  Ic:  Threads  Extension  to  POSIX 

3.4.6.10.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.4.6.11  Recovery  and  restart  services  for  long  running  transactions.  (This  RSA  appears  in 
both  part  4  and  part  9.)  Checkpoint  and  restart  is  provided  for  interactive  transactions  on 
centralized  systems  via  the  SQL  "commit"  and  "rollback"  commands,  and  for  short-running 
transactions  on  distributed  systems  via  the  2-Phase  Commit  specified  in  the  ISO  CCR  standard. 
However,  long  running  transactions  require  standardized  checkpointing,  restarting,  and  migration 
services  and  interfaces  to  prevent  the  loss  of  the  transaction  if  a  system  fails  or  shuts  down.  Two 
APIs  must  be  standardized  for  this  purpose.  One  will  allow  application  control  of  the  checkpoint 
The  other  will  allow  the  transaction  manager  to  control  the  checkpointing  and  restart  activity  over 
a  range  of  heterogeneous  resource  managers. 

3.4.6.11.1  Standards.  Table  3.4-33  presents  standards  for  recovery  and  restart  services  for  long 
running  transactions. 


TABLE  3.4-33  Recovery  and  restart  services  for  long  running  transactions  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPC 

IEEE 

Portable  Operating  Syilem  Interface  (POStX)  -  Part  2:Shtll 
and  Utilibe*  •  Amendment  1:  Batch  Environment 

1003.24:1994 

Informational 

(Approved) 

NPC 

IEEE 

PI003.lt 

Informational 

(Draft) 

NPC 

IEEE 

POStX,  Part  1:  System  API  -  Amendment  x: 
Checkpoint/Re* tart  Interfax!  (C  Language) 

P1003.1m 

Informational 

(Formative) 

3.4.6.11.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6.11.3  Standards  deficiencies.  Based  on  a  requirement  from  the  P1003.15  Batch  Queuing 
Extensions  Standards  Group,  the  POStX.  1  revision  will  specify  application  control  of 
checkpointing.  But  this  specification  is  geared  to  batch  environments,  and  does  not  address  the 
transaction  manager's  control  of  checkpoint,  restart,  or  migration  of  services  needed  for  a 
transaction  processing  environment.  This  need  is  not  being  addressed  other  than  by  de  facto 
solutions. 

P1003.2d  specifies  some  capabilities  needed  for  checkpointing  and  restart  in  batch  environments, 
but  as  a  standard  geared  to  batch  environments,  it  does  not  address  the  transaction  manager's 
control  of  checkpoint,  restart,  or  migration  of  services. 

3.4.6.11.4  Portability  caveats.  Without  standardized  interfaces  to  allow  application  control  of 
checkpointing  and  transaction  manager's  control  of  checkpointing  and  restart  activity,  portability 
and  interoperability  across  heterogeneous  resource  managers  are  nonexistent,  except  for  short- 


April  7,  1997 


3.4-57 


Version  3. 1 


Informal. ;  Technology  Standards  Ouidanc* 


Data  Management  Services 


running  transactions  (which  are  controlled  via  SQL's  "commit"  and  "rollback"  commands  and  via 
ISO's  CCR  standard). 

3.4.6.115  Related  standards.  The  following  standards  are  related  to  recovery  and  restart 
services  or  standards: 

a.  ISO  9041-1:  Basic  Gass  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075: 1992:  SQL  3rd  edition 

c.  IEEE  1003.  lb:  1993:  Real-Time  Extension  to  POSIX 

d.  IEEE  1003.1c;  1995:  Threads  Extension  to  POSIX 

3.4.6.11.6  Recommendations.  There  is  no  recommendation  for  recovery  and  restart  services. 
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3.4.6.12  Interface  to  resource  manager  device  drivers.  For  on-line  transaction  processing 
(OLTP)  environments,  device  driver  interfaces  are  needed  for  devices  commonly  requiring 
transaction  control  (e.g.,  ticket  dispensers,  automated  teller  machines  (ATMs)).  This  will  require 
two  types  of  APIs.  One  API  type  would  be  extensions  to  the  XA  and  XA+  interfaces,  so  these 
interfaces  can  support  device  drivers  as  though  they  were  resource  managers.  The  other  API  is 
the  interface  between  the  application  and  the  device  driver-resource  manager. 

3.4.6.12.1  Standards.  Table  3.4-34  presents  standards  for  interfaces  to  resource  manager  device 
drivers. 


TABLE  3.4-34  Interface  to  resource  manager  device  drivers  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.4.6.12.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.6.12  .3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these 
services  are  not  part  of  any  formal  standard. 

3.4.6.12.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.4.6.12.5  Related  standards.  The  following  standards  are  related  to  resource  manager  device 
driver  interfaces: 

a.  X/Open  C193:  Distributed  TP:  The  XA  Interface 

b.  X/Open  S423:  Distributed  TP:  The  XA+  Specification,  version  2 

3.4.6.12.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.4.6.13  Distributed  queuing.  Distributed  queuing  is  the  waiting  for  services  in  a  distributed 
computing  environment 

3.4.6.13.1  Standards.  Table  3.4-35  presents  standards  for  distributed  queuing. 


TABLE  3.4-35  Distributed  queuing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NP  C 

IEEE 

Portable  Operating  Syttem  Interface  (PQSIX)  •  Part  2tSheU 
and  Utilibei  -  Amendment  I:  Batch  Environment 

1003.2d:1994 

Mandated 

(Approved) 

CPC 

X/Opm 

Distributed  TP:  Reference  Model,  Version  3 

G504  (2/96) 

Informational 

(Approved) 

3.4.6.13-2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  AT&T/USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.4.6. 13 J  Standards  deficiencies.  The  1003.2d  standard  is  geared  to  batch  requests,  not 
transactional  requests  with  associated  persistence  and  rollback  capabilities. 

3.4.6.13.4  Portability  caveats.  Most  internally  built  recoverable  messaging  and  queuing  facilities 
depend  upon  the  underlying  transport  mechanism. 

3.4.6.13.5  Related  standards.  The  IEEE  P1003.1a:  POSIX.l  Revision  is  essential  to  the  use  of 
IEEE  P1003.2d. 

3.4.6.13.6  Recommendations.  Use  the  Pl003.1a  (POSIX.l  Revision)  checkpoint  and  restart 
interface  with  IEEE  1003.2d. 

At  present,  building  a  recoverable  messaging  and  queuing  facility  on  top  of  whatever  transport 
scheme  is  used  to  perform  peer-to-peer  communications  may  be  necessary.  Where  applicable,  use 
the  emerging  P1003.1a  (POSIX.l  Revision)  checkpoint  and  restart  interface.  If  possible,  establish 
an  internal  standardized  interface  that  is  independent  of  the  underlying  transport  mechanism. 
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3.4.6.14  Modeling  services.  Modeling  service  standards  simulate  a  condition  or  activity  in  a 
transaction  processing  system  by  performing  a  set  of  equations  on  a  set  of  data.  A  model  is  a 
mathematical  representation  of  a  device  or  process  used  for  analysis  and  planning. 

3.4.6.14.1  Standards.  Table  3.4-36  presents  standards  for  modeling  services. 


TABLE  3.4-36  Modeling  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

None 

N.A. 

Information*] 

(N.A.) 

3.4.6.14.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.4.6. 14 .3  Standards  deficiencies.  Deficiencies  in  the  modeling  services  standards  are  unknown. 

3.4.6.14.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.4.6.14.5  Related  standards.  The  following  standards  are  related  to  modeling  services  or 
modeling  services  standards: 

a.  ISO  9075:1992:  SQL  3rd  edition 

b.  ISO  10027: 1990  (IRDS  Framework) 

c.  ISO  DP  10728  (IRDS  Services  Interface) 

d.  ANSI  X3. 138- 1988  (IRDS  Requirements  and  Command  Language  &  Panel 
Interface) 

e.  ANSI  X3. 185-1992  (IRDS  Software  Services  Interface) 

f.  NIST  FIPS  156  (IRDS) 

3.4.6.14.6  Recommendations.  There  are  no  standards  to  recommend. 
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3.5  Data  interchange  services.  Data  interchange  services  provide  specialized  support  for 
representing,  storing,  accessing,  and  transmitting  data  (primarily  through  defining  formats). 

NOTE:  Throughout  Part  5,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  I  PC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3.5.1  Characters  and  symbols.  The  characters  and  symbols  (not  symbology)  midlevel  service 
area  includes  standards  for  services  such  as  character  sets  and  typefaces. 

3.5.1. 1  Coded  character  sets.  (This  BSA  appears  in  both  part  5,  Data  Interchange,  and  part  14, 
Internationalization.)  A  character  set  is  a  subset  of  all  letters  in  different  alphabets,  numbers, 
punctuation  marks,  mathematical  symbols,  and  other  characters  used  by  computers.  These 
services  include  the  capability  to  input,  store,  manipulate,  retrieve,  communicate,  and  present  data 
independent  of  the  coding  scheme  used. 

3.5.1.1.1  Standards.  Table  3.5-1  presents  standards  for  coded  character  sets. 


TABLE  3.5-1  Coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISOAEC 

Coded  Graphic  Character  Set  for  Text  Communication  • 
Latin  Alphabet  Second  Edition  (replace*  6937  ptl  &  pt  2) 

6937:1994 

Adopted 

(Approved) 

tPC 

1SO/IEC 

Coded  Graphic  Character  Set  for  U*e  in  the  Preparation  of 
Docuroe  uaed  m  Electrotechnology  anti  for  Information 
Exchange 

1286:1995 

Informational 

(Approved) 

IPC 

ISOAEC 

Coded  Graphic  Character  Set  for  Text  Communication 

6913 

informational 

(Draft) 

IPC 

ISO 

Mathematical  coded  character  »et  for  bibliographic 
information  interchange 

6862 

Informational 

(Draft) 

IPC 

ISO 

Hebrew  alphabet  coded  character  lets  for  bibliographic 
information  int  ^cnge 

8957 

Informational  | 

(Draft)  1 

IPC 

ISO 

Armenian  alphabet  coded  character  set  for  bibliographic 
information  interchange 

10585 

Informational  1 

(Draft)  | 

IPC 

ISO 

Georgian  alphabet  coded  character  set  for  bibliographic 
information  interchange 

10586 

Informational  | 

(Draft)  I 

IPC 

ISOAEC 

Coded  Character  Sets  for  Text  Communication.  Parts  0.  3, 
7.8 

6937-0.3,7,8:1994 

Informational  j 
(Draft) 

IPC' 

ISOAEC 

Coded  Character  Sets  for  Text  Communication,  Parts  4, 5, 

6 

6937-4,5,6 

Inform  aiional 
(Formaii  ve) 
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35.1.1.2  Alternative  specifications.  Alternative  character  coding  schemes. include  Encoded 
Binary  Decimal  (EBCDC)  and  the  Macintosh  character  set 

3 .5.1. 1.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set 

35.1.1.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

35.1.15  Related  standards.  The  following  standards  are  related  to  coded  character  set 
standards: 

a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  Optical  Character  Recognition  (OCR)  Character  Code  Sets: 

(1)  SO  1073-1:1976:  Alphanumeric  character  sets  for  optical  recognition-  Part 
1:  Character  set  OCR- A  -  Shapes  and  dimensions  of  the  printed  image 

(2)  SO  1073-2: 1976:  Alphanumeric  character  sets  for  optical  recognition-  Part 
2:  Character  set  OCR-B  —  Shapes  and  dimensions  of  the  printed  image 

(3)  SO  1831:1980:  Printing  specifications  for  optical  character  recognition 

(4)  SO  2033: 1983:  Information  processing  —  Coding  of  machine  readable 
characters  (MICR  and  OCR) 

c.  Magnetic  Ink  Character  Recognition  (MICR)  Character  Sets 

(1)  SO  2033:1983:  Information  processing  —  Coding  of  machine  readable 
characters  (MICR  and  OCR) 

(2)  SO  1004:1995:  Information  Processing  -  Magnetic  ink  character 
recognition  -  Print  specifications 

35.1.1.6  Recommendations.  ISO  6937  is  recommended  for  ordinary  English-only  alphabetic 
applications. 
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35.1.2  Font  information  interchange.  (This  BSA  appears  in  part  S,  Data  Interchange,  and  part 
12,  Multimedia.)  Font  information  interchange  standards  specify  the  encoding  of  font  resource 
information  for  use  in  document  processing  environments.  Font  interchange  deals  with  the 
exchange  of  character  fonts,  such  as  Times  Roman  or  Helvetica,  and  related  information  as 
opposed  to  simple  exchange  of  character  encodings,  which  do  not  include  font  information. 

3.5.1.2.1  Standards.  Table  3.S-2  presents  standards  for  font  information  interchange. 


TABLE  35-2  Font  information  interchange  standards 


j  "  mdard 

<ype 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

n>c 

ISO/IEC 

Pont  Information  Interchange,  Part  1 :  Architecture 
(Corrigendum  1-1992,  Corrigendra  2- 1994) 

9541-1:1991 

Adopted 

(Approved) 

IPC 

ISO/IRC 

Pont  Information  Interchange,  Part  2:  Interchange  Format 
(Corrigendum  1-1993) 

9541-2:1991 

Adopted 

(Approved) 

IPC 

1SOAEC 

Font  Information  Interchange,  Part  3:  Glyph  Shape 
RepreaoUation 

9541-3:1994 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Pont  Information  Interchange  -  Procedure  for  Regiitradon 
of  Glyph  and  Glyph  Collection  Identifier! 

10036:1993 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  90:1983 

Informational 

(Approved) 

CPN-C 

Adobe 

PoitScript  Type  I  -  Outline! 

PS  Tech.  Manuals 

bifotmational 

(Approved) 

CPN-C 

Microsoft 

TrueType  -  Outline* 

IT  Tech.  Manual* 

Informational 

(Approved) 

IPC 

ISO/EEC 

Font  Information  Interchange,  Part  A’  Character  Collection! 

9541-4 

Informational 

(Draft) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  5:  Font  Attribute*  and 
Character  Model 

9541-5 

Informational 

(Draft) 

IPC 

1SO/IEC 

Font  Information  Interchange,  Part  6:  Font  and  Character 
Attribute  Subcet*  and  Application 

9541-6 

Informational 

(Draft) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  7:  Font  Interchange 
Format 

9541-7 

Informational  1 
(Draft) 

3.5.1.2.2  Alternative  specifications.  Alternative  specifications  include  TrueType  and  PostScript. 

35.1.2.3  Standards  deficiencies.  There  is  and  will  be  very  little  standardization  of  font  names, 
because  of  copyright  concerns.  None  of  the  existing  font  interchange  standards  accurately  enable 
font  substitution.  However,  many  systems  are  attempting  font  substitution,  that  is  i  'ring  a 
specified  font  with  one  that  is  similar,  such  as  substituting  TrueType  Arial  for  Posri  ,,pt 
Helvetica. 

No  standard  exists  for  three-dimensional  font  families,  although  such  text  is  becoming  popular  in 
display  text  applications,  such  as  advertising  and  presentations. 
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3 5. 1.2.4  Portability  caveats.  Target  presentation  systems  and  viewers  may  not  have  the  required 
fonts  to  construct  the  called-for  text  in  a  presentation  system.  Pont  substitution  may  result  in  an 
unexpected  text  presentation.  Outline  font  geometry  also  can  be  repress  cd  as  two-dimensional 
graphics  geometry,  which  eliminates  the  need  to  support  a  specific  font  on  a  target  platform. 

3 Ji.  1.2.5  Related  standards.  Standards  related  to  font  information  interchange  standards  are: 

a.  ISO  8632:  Computer  Graphics  Metafile  (CGM) 

b.  X  Logical  Font  Description  (see  part  3) 

c.  PostScript  Level  2  (starting  to  be  used  for  colored  text) 

3.5.1.2.6  Recommendations.  If  CGM  is  being  used,  then  ISO  8632-1  DAM  3  also  is  needed  for 
font  information  exchange  along  with  ISO  9541.  The  ISO  9541  specifies  the  architecture  and 
format  for  various  shape  descriptions  to  be  used  in  document  processing  environments  that 
recognize  Abstract  Syntax  Notation  (ASN).l  or  SGML  parsing  algorithms.  ISO  9541  uses  Adobe 
System's  PostScript  Type-I  font  technology  and  file  formats.  The  ISO  9541  is  recommended  for 
font  information  exchange. 

For  some  applications,  such  as  view-only  kiosks  and  presentations,  convert  text  to  a  graphics 
foimat  to  avoid  unknown  font  resource  issues.  Use  fonts  that  are  in  common  usage  for  cross¬ 
platform  work. 
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3.5. 1.3  Date  and  time  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part 
14,  Internationalization.)  Date  and  time  representation  and  storage  require  consideration  and 
standardization.  Problems  include  representation  of  twelve  or  twenty-four  hour  time,  the  order  in 
which  the  day  and  month  are  presented,  and  dropping  of  the  century  digits  from  the  year. 

3.5.1.3.1  Standards.  Table  3.5-3  presents  standards  for  date  and  time  representation. 


TABLE  3.5-3  Date  and  time  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

UPC 

DOD 

Defeoie  Data  Dictionary  System  (DDDS),  Version  3.2, 
May  1996 

DDDS  Ver.  3.2 

Mandated 

(Approved) 

GPC 

NIST 

FIPS  PUB  4- 
1:1988  Change 
Notice  3/25/96 

Informational 

(Approved) 

GPC 

NIST 

Representation  of  Local  Time  of  (he  Day  for  Information 
Exchange  (adopts  ANSI  X3.43-1986) 

FIPS  PUB  58- 

1:1988 

Informational 

(Approved) 

GPC 

NIST 

Representations  of  Universal  Time,  Local  Time 
Differentials,  and  US  Tune  Zone  References  for 
Information  Interchange  (Adopts  ANSI  X3.5 1-1979) 

FIPS  PUB  59:1979 

Informational 

(Approved-, 

[PC 

ISO 

Representation  of  Dales  and  Tunes 

8601:1988 

Informational 

(Approved) 

NPC 

ANSI 

Representation  of  Calendar  Date  and  Ordinal  Date  for 
Information  Interchange 

X3.  30-1985 
(R 1 99 1 ) 

Informational 

(Approved) 

NPC 

ANSI 

Representation  of  Local  Time  of  Day  for  Information 
Interchange 

X3.  43-1986 
(R1992) 

Informational 

(Approved) 

NPC 

ANSI 

■aawaaaM 

X3.  51-1994 

Informational 

(Approved) 

NPC 

ANSI/EIA 

Source  and  Dale  Code  Marking 

476-A:  1987 

Informational  | 
(Approved)  | 

3.5.1.3.2  Alternative  specifications.  There  are  no  other  available  specifications. 

3.5.1.3.3  Standards  deficiencies.  In  the  early  days  of  computer  technology,  information  storage 
space  was  at  a  premium.  Engineers  saved  space  by  using  only  the  last  two  digits  of  the  year  rather 
than  using  full  four-digit  year  representation  since  they  did  not  anticipate  that  existing  systems 
would  still  be  in  operation  in  the  year  2000.  This  is  a  problem  to  be  kept  in  mind  during  data 
design  for  information  systems  and  their  databases.  The  internal  representation  of  the  year  and 
dates  is  expected  to  cause  enormous  difficulties  as  the  year  2000  arrives. 

3.5.1.3.4  Portability  caveats.  The  difference  between  a  little-endian  (i.e.,  1 1  May  1995),  a  big- 
endian  (i.e.,  1995  May  1 1),  and  mixed  mode  (i.e..  May  1 1,  1995)  date  representation  can  be  a 
portability  problem  for  systems.  The  stated  DoD  data  element  for  date  format  is 
"YYYYMMDD"  where  YYYY  is  the  year,  MM  is  the  month,  and  DD  is  the  day.  NIST  highly 
recommends  that  four-digit  year  elements  be  used  and  that  two-digit  year  elements  NOT  be  used 
for  data  interchange.  On  March  25,  1996  NIST  published  a  change  notice  to  FIPS  4-1  that  highly 
recommends  four-digit  year  elements,  and  states  that  two-year  elements  specified  in  ANSI 
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X3.30: 1985  (R19S1)  should  not  be  used  for  the  purpose  of  any  data  interchange  among  U.S. 
Government  agencies. 

The  eight-digit  date  format  is  required  for  all  system  interfaces  and  data  exchanges  in  DoD.  The 
Defense  Data  Dictionary  System  (DDDS)  Generic  Element  Name:  Date  is  mandatory  in  the 
design  of  DoD  databases  (DoD  Directive  8320.1,  Sept  26, 1991).  The  DoD  data  standard  is 
required  to  be  used  in  new  systems  developments,  including  commercial  off-the-shelf 
replacements;  migration  systems;  and  any  system  receiving  major  changes. 

3.5. 1.3.5  Related  standards.  The  following  standard  is  related  to  date  and  time  representation: 
a.  NIST  FIPS  34,  Guide  for  the  Use  of  International  System  of  Units  in  FIPS  PUBS 

3.5.1.3.6  Recommendations.  For  purposes  of  data  interchange,  DoD  requires  that  year,  month, 
and  day  be  represented  as  'YYYYMMDD'. 
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3.5. 1.4  Seven-bit  coded  character  sets.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part 
14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be  uniquely 
identified  using  a  seven-bit  number  (i.e.,  128  characters  numbered  0  to  127). 

3.5.1.4.1  Standards.  Table  3.5-4  presents  standards  for  seven-bit  coded  character  sets. 


TABLE  3 .5-4  Seven-bit  coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Code  for  Information  Interchange,  IU  Representation*, 
Subteta,  and  Extension*  (ASCII)  (adopt!  ANSI  X3.4- 
1986/R  1992.  X3.32-1990.  X3.41-1974) 

FIPS  PUB  1- 

2:1984 

Adopted 

(Approved) 

IPC 

ISO 

ISO  7-Bit  Coded  Character  Set  for  Information  Exchange 

646:1991 

Adopted 

(Approved) 

IPC 

ISO 

Information  Proceating  -  Representation  of  the  7-Bit  Coded 
Character  Set  on  Punched  Tape 

1113-1979 

Informational 

(Approved) 

NPC 

ANSI 

Code  Exleruion  Technique*  for  Use  with  the  7-Bit  Coded 
Character  Set  of  American  National  Standard  Code  for 
Information  Interchange 

X3. 41-1974 

Informational 

(Approved) 

IPC 

ISO 

9036:1987 

Informational 

(Approved) 

IPC 

NATO 

Parameter*  and  Practice*  for  the  Uie  of  the  NATO  7-Bit 
Code 

STANAG  5036 

Informational 

(Approved) 

IPC 

NATO 

Interoperable  Character!  for  Teleprinter*  Uiing  NATO  7- 
BitCode 

STANAG  5045 

Informational 

(Approved) 

ISO  646  describes  a  set  of  128  control,  alphabetic,  digit,  and  symbol  characters.  It  includes  the 
use  of  the  control  characters  and  describes  the  option  of  national  replacement  characters.  It  is  the 
standard  that  formed  the  basis  for  creating  additional  standards  that  extend  the  character  set  to 
include  many  languages.  A  variant,  IcO  646:1991  IRV,  left  open  an  additional  128  codes  to  be 
used  to  represent  symbols  for  other  languages. 

3.5.1.4.2  Alternative  specifications.  Alternative  character  coding  schemes  include  Encoded 
Binary  Decimal  (EBCDC)  and  the  Macintosh  character  set. 

3.5. 1.4.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.5. 1.4.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets.  FIPS  19-2,  a  catalog  of  widely  used  code  sets  that  lists 
and  briefly  describes  code  sets  in  wide  use  in  the  United  States  and  might  be  used  in  Federal  data 
systems,  may  be  helpful  to  consult. 

3.5. 1.4.5  Related  standards.  The  following  standards  are  related  to  seven-bit  coded  character 
sets: 
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a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  Optical  Character  Recognition  Character  Code  Sets 

c.  ISO  3275: 1974--  Implementation  of  the  7-bit  coded  character  set  and  its  7-bit  and 
8-bit  extensions  on  3,81  mm  magnetic  cassette  for  data  interchange 

d.  ISO  6586: 1980  -  Implementation  of  the  ISO  7-bit  and  8-bit  coded  character  sets 
on  punched  cards 

e.  ISO  1 1 13:1979  --  Representation  of  the  7-bit  coded  character  set  on  punched  tape 

3.5.1.4.6  Recommendations.  FIPS  1-2,  which  adopts  the  ASCII  character  set,  is  recommended 
for  common  applications.  ISO  646  is  also  recommended. 
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3.5. 1.5  Eight-bit  coded  character  sets.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part 
14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be  uniquely 
identified  using  an  eight-bit  number  (typically,  256  characters  numbered  0  to  255). 

3.5.1.5.1  Standards.  Table  3.5-5  presents  standards  for  eight-bit  coded  character  sets. 


TABLE  3 .5-5  Eight-bit  coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC/IPC 

ANSI/ISO/IEC 

ISO  8-Bit  Code  for  Information  Interchange  -  Structure  and 
Ruled  for  Implementation  (8-Bit  ASCII)  (Revision  end 
reded  Enation  of  ANSI  X3. 134.1) 

4873:1991 

Adopted 

(Approved) 

IPO 

ISO/IEC 

Standardized  Coded  Graphic  Chancier  Sets  for  Use  in  8- 
BH  Codes 

10367:1991 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Coded  Character  Set 

6(1991) 

informational 

(Approved) 

IPC 

ECMA 

8-Bit  Coded  Character  Set  Structure  and  Rules 

43(1991) 

Informational 

(Approved) 

3.5. 1.5. 2  Alternative  specifications.  Alternative  character  coding  schemes  include  EBCDC  and 
the  Macintosh  character  set. 

3.5.1.5  J  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.5.1.5.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.5. 1.5.5  Related  standards.  The  following  standards  are  related  to  eight-bit  coded  character 
sets: 


a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  OCR  Character  Code  Sets 

c.  ISO  3275: 1974-  Implementation  of  the  7-bit  coded  character  set  and  its  7-bit  and 
8-bit  extensions  on  3,8 1  mm  magnetic  cassette  for  data  interchange 

d.  ISO  6586: 1980  —  Implementation  of  the  ISO  7-bit  and  8-bit  coded  character  sets 
on  punched  cards 

3.5. 1.5.6  Recommendations.  ISO  4873  is  recommended. 
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3.5. 1.6  Eight-bit  single  byte  character  9ets.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be 
uniquely  identified  using  an  eight-bit  number  in  a  single  byte  (typically,  but  not  always,  256 
characters  numbered  0  to  255). 

3.5.1.6.1  Standards.  Table  3.5-6  presents  standards  for  eight-bit  single  byte  character  sets. 


TABLE  3 .5-6  Eight-bit  single  byte  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/ffiC 

ISO  8-Bit  Single-Byte  Coded  Graphic  Character  Sett:  Parti 
1-9 

8859-1  to  9: 1987- 
1989 

Mandated 

(Approved) 

IPC 

ISO/IEC 

ISO  8-Bit  Single- Byte  Coded  Graphic  Character  Sett:  Part 
10:  Latin  Alphabet  Set  No,  6 

8859-10:1992 

Informational 

(Approved) 

IPC 

ECMA 

8- Bit  Single-Byte  Coded  Graphic  Character  Sett,  Latin 
Alphabett  No.  1  to  No.  4 

94(1986) 

Informational 

(Approved) 

IPC 

EC  VIA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sett  - 
Latin/Cyrillic  Alphabet 

113  (1988) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sett  - 
Latin/Arabic  Alphabet 

114  (1986) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sett  • 
Latin/Greek  Alphabet 

118(1986) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  SinglecByte  Coded  Graphic  Character  Sett  - 
Latin/Hebrew  Alphabet 

121  (1987) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Seu,  Latin 
Alphabet  No.  5 

128(1988) 

>  'tmaiional 
(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sett  -  Latin 
Alphabet  No,  6 

144  (1992) 

Informational 

(Approved) 

ISO  8859  defines  a  set  of  191  graphic  characters  with  a  single  8-bit  byte.  It  uses  the  characters 
0x20  through  0x7F  to  represent  those  used  in  the  US-ASCI1  (ISO  646)  set. 

3.5.1.6.2  Alternative  specifications.  Alternative  character  coding  schemes  include  EBCDC  and 
the  Macintosh  character  set. 

3.5. 1.6.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.5.1.6.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.5.1.6.5  Related  standards.  The  following  standards  are  related  to  eight-bit  single  byte 
character  sets: 
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a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  Optical  Character  Recognition  Character  Code  Sets 

3.5. 1.6. 6  Recommendations.  ISO  S859,  parts  1-9,  is  recommended. 
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3.5. 1.7  Control  functions.  (This  BSA  appears  in  part  5,  Data  Interchange  and  part  14, 
Internationalization.)  This  service  area  is  for  definition  and  coding  of  control  functions  for 
inclusion  in  character  sets. 

3.5.1.7.1  Standards.  Table  3.5-7  presents  standards  for  control  functions. 


TABLE  3.5-7  Control  functions  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Octroi  Function!  for  ISO  7-Bit  and  8-Bit  Coded  Quarter 
Set* 

6429:1992 

Adopted 

(Approved) 

GPC 

NIST 

Addition*]  Control*  for  U*e  with  American  Nad  on*] 
Standard  Code  for  Information  Interchange  (adopt*  ANSI 
X3.64-1979/R1990) 

FIPS  PUB  86:1981 

Informational 

(Approved) 

IPC 

ISO 

Information  Proceaaing  -  Graphical  Representation*  for  the 
Control  Character!  of  the  7-Bit  Coded  Chancier  Set 

2047:1975 

Informational 

(Approved) 

IPC 

ISO 

Bibliographic  control  character* 

6630:1986 

Informational 

(Approved) 

IPC 

ECMA 

Control  Function*  for  Coded  Character  Set* 

48(1991) 

Informational 

(Approved) 

IPC 

ECMA 

17  0968) 

Informational 

(Canceled) 

ISO  6429  defines  a  7-bit,  7-bit  extended,  8-bit,  and  an  8-bit  extended  character  set  control. 

3.5. 1.7.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5. 1.7.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.1.7.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.5.1.7.5  Related  standards.  There  are  no  related  standards. 

3.5.1.7.6  Recommendations.  ISO  6429  is  recommended. 
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3 .5.1.8  Character  set  conversion.  (This  BSA  appears  in  part  S,  Data  Interchange,  and  part  14, 
Internationalization.)  Character  set  conversion  deals  with  the  problem  of  translating  from  one 
character  set  to  another. 

3.5.1.8.1  Standards.  Table  3.5-8  presents  standards  for  character  set  conversion. 


TABLE  3.5-8  Character  set  conversion  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IHm 

IPC 

ISO 

Convemon  Between  the  Two  Coded  Character  Sets  of  ISO 
646  and  ISO  6937-2  and  the  CCITT  International 
Telegraph  Alphabet  No.  2  0TA2) 

6936:1988 

Informational 

(Approved) 

IPC 

ISO 

Convemon  Between  the  Two  Coded  Character  Seta  of  ISO 
646  and  ISO  6937-2  and  the  CCITT  International 
Telegraph  Alphabet  No.  2  (ITA2):  Reviiioru 

6936  Revirioiu 

Informational 

(Formative) 

ISO  6936  specifies  conversion  between  the  58  character  ITA2  set  and  the  128  character  ISO  646 
set. 


3.5.1.8.2  Alternative  specifications.  There  are  alternative  specifications  that  are  sometimes 
necessary: 


a.  Mac  to  ASCII 

b.  EBCDC  to  ASCII 

3.5. 1.8.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.5.1.8.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.5.1.8.5  Related  standards.  The  following  standards  are  related  to  character  sets  conversion: 

a.  Transliteration  standards. 

3.5.1.8.6  Recommendations.  There  are  no  recommendations.  Character  set  conversion  standards 
depend  on  which  sets  are  involved. 
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3 .5. 1.9  Code  extension  techniques.  (This  BSA  appears  in  part  3,  Data  Interchange,  and  part  14, 
Intemationalizaticn.)  There  is  also  a  need  to  define  standard  techniques  for  expanding  the  number 
of  characters  represented  by  a  character  set  Switching  between  character  sets  in  mid-string  is 
done  by  escape  sequences. 

3.S.1.9.1  Standards.  Table  3.5-9  presents  standards  for  code  extension  i.  '.hniques. 


TABLE  3.5-9  Code  extension  techniques  standards 


Standard 

Type 

H 

Standard 

Standard 

Reference 

mu 

IPC 

ISO/lEC 

2022:1994 

Adopted 

(Approved) 

DPC 

ISO 

3275:1974 

Informational 

(Approved) 

IPC 

ISO 

Ex  tern  »n  of  the  Latin  Alphabet  Coded  Character  Set  for 
Bibliographic  Information  Interchange 

5426:1983 

Informational 

(Approved) 

[PC 

ISO 

Extension  of  the  Cyrillic  Alphabet  Coded  Character  Set  for 
Bibliographic  Information  Interchange 

5427:1984 

Informational 

(Approved) 

IPC 

ISO 

Greek  Alphabet  Coded  Character  Set  for  Bibliographic 
Information  Interchange 

5428:1984 

Informational 

(Approved) 

IPC 

ISO 

Documentation  -  African  Coded  Chancier  Set  for 
Bibliographic  Information  Interchange 

6438:1983 

Informational 

(Approved) 

[PC 

ECMA 

Code  Extension  Techniques 

35  (1994) 

Informational 

(Approved) 

IPC 

ISO 

Extension  of  the  Cyrillic  alphabet  ooded  character  set  for 
non-Slavonic  languages  for  bibliographic  information 
interchange 

10754 

Informational 

(Draft) 

tPC 

ISO/IEC 

ISP  for  Code  Structures  Based  on  ISO/IEC  2022  Part  1 : 
FCSl II -2022 Option  l 

12070-1:1995 

Informational 

(Draft) 

[PC 

ISO 

Extension  of  the  Latin  Alphabet  Coded  Character  Set  for 
Bibliographic  Information  Interchange:  part  2:  Latin 
characters  used  in  minor  European  languages  and  obsolete 

_  lypunrcpfry _ _ 

5426-2 

Informational 

(Draft) 

IPC 

ISO 

Extensions  of  the  Arabic  alphabet  coded  character  set  for 
bibliographic  information  interchange 

11822 

Informational 

(Draft) 

[PC 

ISO/IEC 

ISO  7-Bit  and  8-Bit  Coded  Character  Sets  -  Code 
Extension  Techniques 

2022:1986 

Informational 

(Superseded) 

3.5.1.9.2  Alternative  specifications.  Alternative  specifications  would  include  other,  larger,  forms 
of  character  sets  (8-bit  instead  of  7-bit,  or  multiple-octet  sets  instead  of  8-bit). 

3.5.1.9.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.1.5.4  Portability  caveats.  Few  systems  support  the  ISO  2022  encoding  architecture  because 
escape  sequences  present  difficulties  to  processing. 


3.5. 1.9.5  Related  standards.  There  are  no  related  standards. 


April  7,  1997 


3.5-14 


Version  3. 1 


3.5. 1.9.6  Recommendations.  ISO  2022  is  recommended. 
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3.5.1.10  Universal  character  sets.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  14, 
Internationalization.)  Universal  character  sets  are  an  approach  to  defining  the  broadest  possible 
character  set  This  involves  using  more  than  an  8-bit  code.  Use  of  a  16-bit  code  allows  for  a 
character  set  of  32,768  characters,  which  is  sufficient  to  cover  several  complete  alphabets, 
including  accented  letters.  The  object  of  UCS  is  to  represent  the  written  form  of  world  languages 
unambiguously  to  facilit  "  information  interchange 


3.5.1.10.1  Standards.  Table  3.5-10  presents  standards  for  universal  character  sets. 


TABLE  3.5-10  Universal  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISG/EC 

Univeml  Multiple-Octet  Coded  Character  Set  (UCS),  Put 

1:  Architecture  and  Basic  Multilingual  Plane  (with 
Technical  Corrigendum  1:  1996) 

10646-1:1993 

Mandated 

(Approved) 

CPC 

X/Op« 

Universal  Multiple-Octet  Coded  Character  Set  Coexistence 
and  Migration 

E401  (3/94) 

Informal]  orul 
(Approved) 

CPC 

Unicode 

Consortium 

Unicode  version  I.I 

UCS-2 

Informational 

(Approved) 

IPC 

ISO/IEC 

Universal  Multiple-Octet  Coded  Character  Set,  Part  1 : 
Architecture  and  Basic  Multilingual  Plane,  Amend  1 : 
Transform  Format  for  16  Planes  of  Group  00  (UTF- 16), 
Amend  2:  UCS  Transform  Formal  8  (UTF- 8),  Amend  3: 
control  characters,  Amend  4:  remove  UTF- 1  to  a 

10646-1,  Am  1- 
4:1993 

Informational 

(Draft) 

IPC 

ISO 

Univeml  Multi  pie- Octet  Coded  Character  Set,  Part  1 : 
Architecture  and  Basic  Multilingual  Plane.  Amend  5: 
Korean  Hangul,  Amend  6:  Tibetan  additions,  Amend  7, 
Amend  8:  Han  unification 

10646-1:  DAM  5-8 

Informational 

(Draft) 

ISO  10646  is  an  extension  of  ISO  8859.  A  separate  part  of  8859  is  defined  for  a  variety  of 
character  sets.  The  10646  is  multiple-octet  character  set  that  can  be  encoded  using  8-,  16-,  or  32- 
bit  character  sizes.  All  existing  character  sets  in  8859  are  included  as  pages  in  the  10646 
encoding,  along  with  virtually  all  known  characters  on  the  planet  The  10646  is  effectively  the 
dictionary  of  coded  character  sets. 

3.5.1.10.2  Alternative  specifications.  There  are  no  alternatives  for  a  universal  character  set. 

3.5.1.10.3  Standards  deficiencies.  Only  a  small  number  of  modem  languages  are  unrepresentable 
by  these  standards,  but  are  expected  to  be  supported  soon. 

3.5.1.10.4  Portability  caveats.  The  portability  problems  with  universal  character  sets  involve 
their  multi-byte  nature.  Translation  to  and  from  single-byte  sets  is  full  of  chances  for  errors. 

3.5.1.10.5  Related  standards.  There  are  no  related  standards. 

3.5.1.10.6  Recommendations.  If  multiple-octet  representations  (16-  or  32-bit)  of  characters  are 
required,  ISO  10646  is  recommended. 
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3.5.1.11  External  data  lepresentatlon.  External  data  representation  standards  specify  the 
encoding  for  common,  low-level  data  types  to  resolve  the  differences  in  data  type  representation 
between  platforms  and  applications. 

3.5.1.11.1  Standards.  Table  3.5-1 1  presents  standards  for  external  data  representation. 


TABLE  3.5-11  External  data  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-T 

External  Data  Representation  (XDR)  for  use  with  X.400 

X.409 

Adopted 

(Approved) 

NPC 

IFFE 

Open  Systems  Interconnection  (OS  I)  Abatract  Dale 
Manipulation  -  Application  Program  Interface  (API) 
(Language  Independent) 

1224:1993 

Informational 

(Approved) 

NPC 

IFFK 

Teat  Method*  for  Meanuing  Conformance  to  Open 
Systems  Interconnection  (OS I)  Abatract  Data  Manipulation 
-  Application  Program  Interface  (API)  (Language 
Independent) 

1326:1993 

- 

Informational 

(Approved) 

NPC 

gyai^fwiaa 

1327:1993 

Informational 

(Approved) 

NPC 

fPPF. 

Teat  Method*  for  Meaauring  Conformance  to  Open 
Systems  Interconnection  (OS I)  Abstract  Data  Manipulation 

C  Language  Interfaces  •  Binding  for  Application  Program 
Interface  (API) 

1328:1993 

Informational 

(Approved) 

IPC 

ISO 

Specification  for  a  Data  Descriptive  File  for  Information 
Interchange  (DDF) 

8211:1985 

Informational 

(Approved) 

IPC 

1SO/IEC 

OSI  Specification  of  Abatract  Syntax  Notation  One 
(ASN.I) 

8824:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Abstract  Syntax  Notation  One  (ASN.I):  Specification 
of  Basic  Notation 

8824-1:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Abstract  Syntax  Notation  One  (ASN.I):  Information 
Object  Specification 

8824-2:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Abatract  Syntax  Notation  One  (ASN.I):  Constraint 
Specification 

8824-3:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Abstract  Syntax  Notation  One  (ASN.I): 
Parameterization  of  ASN.I  Specifications 

8824-4:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Specification  of  Basic  Encoding  Rules  (BER)  for 
Abstract  Syntax  Notation  One  (ASN.I) 

8825:1990 

Infonnalional 

(Approved) 

IPC 

ISO/IEC 

OSI  --  ASN.I  encoding  rules:  Specification  of  Basic 
Encoding  Rules  (BER),  Canonical  Encoding  Rules  (CER) 
and  Distinguished  Encoding  Rules  (DER) 

8825-1:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  -  ASN.I  encoding  rules:  Specification  of  Packed 
Encoding  Rules  (PER) 

8825-2:1996 

Informational 

(Approved) 

CPC 

X/Open 

Protocols  for  X/Open  PC  Internetworking:  (PC)NFS 

D030  (8/90) 

Informational 

(Approved) 

CPC 

OSF 

External  Data  Representation  (XDR)  (For  use  with  DCF’s 
RPC) 

DCEXDR 

Informational 

(Approved) 

GPC 

NIST 

Catalog  of  Widely  Used  Code  Sets 

FIPS  PUB  19- 
2:1992 

Informational 

(Approved) 

GPC 

NIST 

Specification  fora  Dala  Descriptive  File  for  Information 
Interchange  (DDF)  (adopts  ANSI/ISO  821 FI985/R 1992) 

FIPS  PUB 
123:1986 

Informational 

(Approved) 

April  7,  1997 


3.5- 1 1 


Version  3.1 


information  Technology  Standards  Guidance 


Data  Interchange  Services 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

IETF 

XDR:  Extern*]  Dm*  Representation  Standard  (i*me  u 
X/Open  XDR) 

RFC  1014:1987 

Informational 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  Open  Systems 
Interconnections  -  Specification  of  Abstract  Syntax 
Notation  1  (ASN.l) 

STANAQ  4258 
1993 

Informational 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  Open  System*  Interconnection 
-  Encoding  Rule*  for  ASN.l 

CTANAG  4259 

Info  [national 
(Approved) 

IPC 

ITU-T 

Specification  of  Abstract  Syntax  Notation  one  (ASN.l)  - 
OSI  Model  and  Natation,  Service  Definition 

X.208  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Specification  of  Basic  Encoding  Rule*  for  Abstract  Syntax 
Notation  One  (ASN.  1)  •  Data  Communication  Netwoika  • 
Open  Systems  Interconnection  (OSI)  Model  and  Notation, 
Service  Definition 

X.209  (1989) 

Informational 

(Approved) 

IPC 

ISOyTEC 

Open  Systems  Interconnection  -  Conformance  Teat  Suite 
for  the  Presentation  Layer  -  Part  2:  Teat  Suite  Structure  and 
Teat  Purpose*  for  die  ASN.l  Basic  Encodings 

10729-2:1993 

Informational 

(Draft) 

IPC 

ISO/1EC 

OSI  Abstract  Syntax  Notation  one  (ASN.l)  Revision:  Part 

S:  Character  Sets 

8824-5 

Informational 

(Formative) 

IPC 

ISO/IEC 

OSI  Specification  of  ASN.  I  Basic  Encoding  Rules 
Revision:  Part  4:  Light  Weight  Encoding  Rules  (LWER) 

8825-4 

Informational 

(Formative) 

3.5.1.11.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.5.1.11.3  Standards  deficiencies.  ASN.l  is  a  highly  complex,  difficult-to-use  language  for 
describing  Open  Systems  Interconnect  (OSI)  objects,  with  a  complicated  set  of  Basic  Encoding 
Rules.  Neither  the  ASN.  1  nor  the  X.409  standards  are  suitable  for  use  with  generic  remote 
procedure  calls  used  in  application  development.  The  1987  Basic  Encoding  Rules  (BER) 
international  standard,  which  is  specified  by  the  Government  Open  Systems  Interconnection 
Profile  (GOSIP),  provides  a  lengthy,  verbose  representation,  compared  to  the  more  compact 
representation  achieved  by  the  Distinguished  Encoding  Rules  (DER)  (8824  Revision:  Part  2).  It 
encodes  and  decodes  data  slower  than  the  Light  Weight  Encoding  Rules  (LWER)  (8825  Revision: 
Part  4).  Request  for  Comment  (RFC)  1014,  developed  originally  by  Sun  Microsystems  for  use 
with  the  Network  File  System  (NFS),  is  an  external  data  representation  specification  to  describe  C 
language  data  types  only. 

3.5.1.11.4  Portability  caveats.  ISO  8824  ASN.  1  specifications  are  compatible  with  the 
International  Telecommunications  Union  (ITU)  X.208  ASN.l,  except  for  a  few  ISO  extensions 
that  are  not  backward  compatible  with  X.208. 

X/Open's  External  Data  Representation  (XDR)  specification,  developed  initially  by  Sun 
Microsystems  for  use  with  NFS,  is  not  compatible  with  the  Open  Software  Foundation's  (OSF's) 
Distributed  Computing  Environment  (DCE)  Remote  Procedure  Call  (RPC)  XDR  (developed 
initially  by  Apollo  Computer). 
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3.5.1.11.5  Related  standards.  The  following  standards  are  related  to  external  data  representation 
or  external  data  representation  standards: 

a.  X/Open  Cl  80:  OSI-Abstract-Data-Manipulation  API  (XOM),  which  provides  an 
easier-to-use  canonical  representation  and  tools  for  manipulating  ASN.l  objects 

b.  RPC:  ISO  DIS  1 1578,  Parts  1-4,  which  will  need  a  standardized  external  data 
representation  for  use  in  open-client  server  computing  and  cooperative  processing 

3.5.1.11.6  Recommendations.  Specification  of  the  1987  versions  of  ASN.l  and  BER  (ISO  IS 
8824/8825)  is  not  advisable.  These  standards  have  been  revised.  The  earlier  standards  are 
specified  in  OOSIP  2  because  nothing  else  was  available  when  GOS1P  2  was  defined.  X.409  is 
recommended.  OSF  DCE  XDR  is  recommended  for  use  in  distributed  computing  environments. 
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3-5.1.12  Character  set  registration.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part 
14,  Internationalization.)  Character  set  registration  provides  a  mechanism  for  identifying  and 
defining  graphic  character  sets 

3.5.1.12.1  Standards.  Table  3.5-12  presents  standards  for  character  set  registration. 


TABLE  3.5-12  Character  set  registration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

RegiMration  of  Repertoire*  of  Graphic  Character*  from 

ISO/IEC  10367 

7350:1991 

Informational 

(Approved) 

IPO 

ISO 

Procedure  for  regiftration  of  etcap e  aequencei 

2375:1985 

Informational 

(Approved) 

ISO  7350  specifies  procedures  for  preparing,  registering,  publishing,  and  maintaining  the  register 
of  graphic  character  sets  and  procedures  for  assigning  identifiers  to  the  sets. 

33.1.12.2  Alternative  specifications.  There  are  no  alternative  specifications. 

33.1.12.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
3.5.1.12.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 
33.1.123  Related  standards.  The  following  standards  are  related  to  character  set  registration: 

a.  Character  set  standards 

b.  Localization  standards 

c.  Symbols  for  use  with  data  such  as  currency,  date,  time,  numerical  values 
33.1.12.6  Recommendations.  There  are  no  recommendations. 
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3.5.1.13  Currency  and  funds  representation.  (This  BSA  appears  in  part  5,  Data  Interchange, 
and  part  14,  Internationalization.)  Covers  characters  for  and  the  representation  of  currency  and 
monetary  values. 

3.5.1.13.1  Standards.  Table  3.5-13  presents  standards  for  currency  and  funds  representation. 


TABLE  3.5-13  Currency  and  funds  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hj|S 

tPC 

ISO 

Code*  for  the  RepretenUtion  of  Currenciei  and  Fund* 

4217:1990 

Informational 

(Approved) 

3.5.1.13.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.1.13.3  Standards  deficiencies.  Deficiencies  in  the  standard  are  unknown. 

3 .5.1.13.4  Portability  caveats.  Portability  problems  in  the  standard  are  unknown. 

3.5.1.13.5  Related  standards.  Numerical  value  representation  standards  and  internationalization 
locale  specifications  are  related. 

3.5.1.13.6  Recommendations.  ISO  4217  is  recommended. 
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3-5.1.14  Country  name  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  These  standards  provide  for  a  short  character  combination  that  can 
be  used  to  represent  the  names  of  countries. 

3.5.1.14.1  Standards.  Table  3.5-14  presents  standards  for  country  name  representation. 


TABLE  3 £•  14  Country  name  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

C'untriea,  Dependencies,  Are**  of  Special  Sovereignty  and 
their  Principal  Administrative  Diviiioni 

FIPS  PUB  104 
April  1995 

Informational 

(Approved) 

GPC 

NIST 

American  National  Standard  codes  for  Representation  of 
Nantes  of  Counties,  Dependencies,  Areas  of  Special 
Sovereignty  and  their  Principal  Administrative  Divisions 

FTPS  PUB  104-1 

Informational 

(Approved) 

IPC 

ISO 

Codes  for  Representation  of  Names  of  Countries 

3166:1993 

Informational 

(Approved) 

ISO  3166  defines  s  2-letter,  a  3-letter,  and  a  numeric  code  for  each  country.  The  2-letter  names 
are  well-known  and  accepted  as  internet  domain  names.  The  3-letter  codes  are  often  used  in 
international  sports. 

3.5.1.14.2  Alternative  specifications.  Alternative  specifications  would  include  the  international 
codes  to  designate  the  country  of  registration  of  automobiles. 

3.5.1.14.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.1.14.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.5.1.14.5  Related  standards.  There  are  no  related  standards. 

3.5.1.14.6  Recommendations.  There  is  no  recommendation. 
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3.5.1.15  Representation  of  human  sexes.  This  BSA  concerns  the  uniform  representation  of 
human  sexes  for  the  interchange  of  information. 

3.5.1.15.1  Standards.  Table  3.5-15  presents  standards  for  representation  of  human  sexes. 


TABLE  33-15  Representation  of  human  sexes  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO 

Repreienution  of  Hunun  Sexet 

5218:1977 

Informational 

(Approved) 

35.1.15.2  Alternative  specifications.  There  are  no  alternative  specifications. 

35.1.153  Standards  deficiencies.  ISO  5218  does  not  meet  the  requirements  of  specific  medical 
or  scientific  applications. 

35.1.15.4  Portability  caveats.  ISO  5218  does  not  prescribe  file  sequences,  storage,  media, 
programming  languages,  or  other  features  of  information  processing  to  be  used  in  its 
implementation. 

3.5.1.155  Related  standards.  No  related  standards  have  been  identified. 

35.1.15.6  Recommendations.  ISO  5218  is  recommended  for  use. 
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3.5.1.16  Representation  of  names  of  languages.  (This  BSA  appears  in  part  S,  Data 
Interchange,  and  part  14,  Internationalization.)  This  BSA  presents  standards  for  code  to  represent 
the  names  of  languages. 

3.5.1.16.1  Standards.  Table  3.5-16  presents  standards  for  representation  of  names  of  languages. 


TABLE  33-16  Representation  of  names  of  languages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Code  for  the  Representation  of  Name*  of  Language* 

639:1988 

Infoimational 

(Approved) 

NPC 

ANSI/NISO 

Code*  for  Representation  of  Languages  for  Information 
Inteidiange 

Z39.53 

Infoimational 

(Approved) 

33.1.16.2  Alternative  specifications.  Alternative  specifications  may  include  abbreviations  in 
common  use  in  entomology. 

3.5.1.163  Standards  deiiciencies.  Deficiencies  in  the  existing  standards  are  unknown. 

33.1.16.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

33.1.16.5  Related  standards.  The  following  standards  are  related  to  representation  of  names  of 
languages: 

a.  ISO  9: 1 995:  Transliteration  of  Cyrillic  Characters  into  Latin  Characters  -  Slavic 
and  Non-Slavic  Languages 

b.  ISO  233-2: 1993:  Information  and  documentation  -  Transliteration  of  Arabic 
Characters  into  Latin  Characters  -  Part  2:  Arabic  Language  -  Simplified 
Transliteration 

c.  ISO  3602:1989:  Documentation  -  Romanization  of  Japanese  (kana  script) 

d.  ISO  DIS  14962:  ASCII  encoded  English 
3.5.1.16.6  Recommendations.  ISO  639  is  recommended. 
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3.5.1.17  Numerical  value  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  Numerical  value  representation  deals  with  the  presentation  of 
numerical  values  as  character  strings  In  machine-  and  human-  readable  form. 

3.5.1.17.1  Standards.  Table  3.5-17  presents  standards  for  numerical  value  representation. 


TABLE  3.5-17  Numerical  value  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Repreaentalion  of  Numerical  Value*  in  Character  String* 
for  Information  Interchange 

6093:1985 

Informational 

(Approved) 

ISO  6093  specifies  three  presentations  of  numerical  values  as  character  strings  in  machine- 
readable  form  for  data  interchange. 

3.5.1.17.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.1.17.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.1.17.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.5.1.17.5  Related  standards.  The  following  standards  are  related  to  numerical  value 
representation: 


a.  Representation  of  currency 

b.  Representation  of  date/time 

c.  Localization 

d.  ANSI  X3.50  1986/R1992:  Representation  for  U.S.  Customary,  SI,  and  other  Units 
to  be  used  in  Systems  with  limited  character  sets 

e.  ISO  2955: 1993  -  Representation  of  SI  and  other  Units  in  Systems  with  limited 
Character  Sets 

3.5.1.17.6  Recommendations.  ISO  6093  is  recommended. 
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3.5.2  Hardware  applications.  The  following  base  service  areas  deal  with  hardware-based  data 
interchange,  data  storage  issues,  and  hardware  design  support. 

3.5.2. 1  Printer  data  interchange.  Printer  data  interchange  is  performed  by  using  page 
description  languages  to  describe  a  page  to  be  printed  so  the  printer  processor  can  convert  the 
representation  directly  into  a  page  image  for  any  printer. 

3.5.2.1.1  Standards.  Table  3.5-18  presents  standards  for  printer  data  interchange. 


<TABLE_3j5-18_Printer_dataiinterchangestandards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

TPC 

ISO/IEC 

Standard  Page  Deichpdon  Language  (SPDL) 

10180:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  46:  Integrated  Generic  Reaourcei:  VUuaJ  Presentation 

10303.46:1994 

Informational 

(Approved) 

CPN-C 

Adobe 

Encapsulated  PostScript  Format  (EPSF) 

EPSF  Level  1 

Informational 

(Approved) 

CPN-C 

Adobe 

Portable  Document  Format  (PDF) 

PDF 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  •  Text  and  office  iy items  - 
Document  Printing  Application  (DPA)  -  Part  2:  Protocol 
specification 

10175-2:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Text  and  office  systems  - 
Document  Printing  Application  (DPA),  Part  1:  Abstract 
service  definition  and  procedures 

10175-1:1996 

Informational 

(Approved) 

3.5.2.1.2  Alternative  specifications.  The  following  de  facto  specifications  are  available: 

a.  Adobe:  PostScript  and  Display  PostScript 

b.  Hewlett-Packard:  Hewlett-Packard  Page  Description  Language  (HPDL) 

c.  Xerox:  Interpress 

3.5.2.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.2.1.4  Portability  caveats.  ISO  10180,  SPDL,  combines  the  best  of  Adobe  PostScript  and 
Xerox  Interpress,  along  with  enhancements  and  extensions  developed  by  ISO.  However,  it  is  not 
a  superset  of  the  PostScript  and  Interpress  page  description  languages.  The  inclusion  of  parts  of 
each  vendor's  page  description,  as  well  as  the  ISO  extensions,  render  it  incompatible  with  either 
PostScript  or  Interpress. 

Although  it  is  a  proprietary  standard,  EPSF  is  widely  supported  for  importation  of  display  text. 
However,  care  should  be  taken  to  ensure  that  tools  used  to  deliver  titles  support  importation  of 
EPSF.  Many  raster  image  formats  are  candidates  for  this  purpose. 

3.5.2.1.5  Related  standards.  No  standards  are  related  to  page  description  exchange  standards. 
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3 >5.2. 1.6  Recommendations.  If  specifying  SPDLin  a  procurement,  the  specification  of  a 
converter  box  that  converts  formats  such  as  PostScript,  Interpress,  or  HPDL  to  SPDL  is 
recommended.  SPDL  is  a  standard  with  no  commercial  following.  The  proprietary  specifications, 
such  as  PostScript  and  PDF,  are  dominant.  If  used,  EPSF  or  PDF  should  be  considered  as  an 
interim  solution  only  until  a  public  standard  is  available.  Adobe  PDF  is  being  used  frequently  in 
DOD  for  formatting  documents  where  revisions  are  not  required.  However,  PDF  suffers  by  the 
fact  that  it  has  not  been  endorsed  by  an  open  consensus  standards  body. 
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3.5 3,2  Bar  coding.  Bar  code  is  an  array  of  parallel  lines  of  varying  width  used  to  represent  data. 
The  bar  code  is  designed  to  be  read  optically  by  a  data  capturing  device.  Traditional  one¬ 
dimensional  bar  codes  use  the  bar's  width  as  the  code,  and  typically  encode  just  an  identification 
or  account  number.  Two-dimensional  systems  hold  1 ,800  characters  in  an  area  the  size  of  a 
postage  stamp. 

3.5 .2. 2.1  Standards.  Table  3.5-19  presents  standards  for  bar  coding. 


TABLE  3.5-19  Bar  coding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Standard  DOD  Bat  Code  Symbology  (Code  39  Adapted 
for  the  DOD) 

MIL-STD-H89B 
of  8/10/1989 

A*i*.  W 
(.^proved) 

CPC 

UCC 

Serial  Shipping  Container  Code  Baaed  on  Cod;  128 
algorithm 

Informational 

(Approved) 

ffC 

NATO 

NATO  Standard  Bar  Code  Symbology  Printing  and 
Applying  Bar  Code  Labels  (R)  Recommended  Practice  for 
Bar-Coded  Vehicle  Emiirioo  Configuration  Label, 
Recommended  Practice;  October  1993 

STANAG  4329 
1992 

Informational 

(Approved) 

NPC 

ANSI 

Bar  Code  Print  Quality-Guideline 

X3. 182- 1 990 

Informational 

(Approved) 

NPC 

AIM 

Uniform  Symbology  Specification  (USS)-I-2/5  (Interleaved 

2  of  5) 

XS>  1:1993 

Informational 

(Approved) 

NPC 

AIM 

Uniform  Symbology  Specification  (USS)-39  Code  39 

X5-2:1993 

Informational 

(Approved) 

3.S.2.2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 
3.5.2.2J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.2.2.4  Portability  caveats.  Various  bar  code  standards  were  developed  by  one  industry 
organization  and  adopted  by  other  industry  organizations  who  modified  them  slightly  for  specific 
application  areas  or  market  segments.  This  has  led  to  many  different  specifications  that  have 
incompatibilities. 

3.5.2.2.5  Related  standards.  The  following  standards  are  related  to  bar  coding  or  bar  coding 
standards: 

a.  ISO  9735:1988-1992,  Electronic  Data  Interchange  for  Administration,  Commerce, 
and  Transport  (ED1FACT) 

b.  ANSI  X. 1 2- 1986,  Parts  1-22:  Electronic  Data  Interchange  (EDI ) 

c.  ITU-T  Recommendation  X.435,  and  F.435 
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3 .5. 2.2.6  Recommendations.  The  recommended  bar  coding  standard  varies  with  the  market 
sector  and  the  amount  of  information  to  be  squeezed  into  the  code.  For  example,  Codabar  is  used 
extensively  in  retail  price-labeling.  Intermec  Corp.’s  Code  49  is  a  stacked  code  of  bars  and  spaces 
in  horizontal  rows.  One  information-squeezing  code  is  Symbol  Technologies  Inc.'s  PDF  417 
which  is  a  matrix-style  code  that  compresses  up  to  1 ,750  characters  per  symbol.  For  code  39  bar 
coding,  MIL-STD-1 189B  is  recommended. 
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3.5 2  J  Physical  interface.  Physical  interface  standards  deal  with  physical  I/O  connections  and 
storage  systems. 

3.5 .2.3.1  Standards.  Table  3.5-20  presents  standards  for  physical  interface. 


TABLE  3.5-20  Physical  Interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

Interface  between  DTE  end  DCE  for  Operations  with 
PSDN,  or  between  Two  DTE*  by  Dedicated  Circuit 
(•doou  ANSI  X3. 100- 1989) 

FTPS  PUB  100- 
1:1991 

Adopted 

(Approved) 

GPC 

NIST 

4800  and  9600  Biu  per  Second  Two-Wire  Duplex 
Modem*  for  Data  Communication*  Use  on  Telephone- 
Type  Circuit*  (adopt*  CCITT  V.32,  Supersedes  FTPS  134- 

1)  _  .. 

FIPS  PUB 
166:1992 

Adopted 

(Approved) 

GPC 

NIST 

9600  bp*  Four-Wire  Duplex  Modem*  for  Data 
Communication*  Uae  on  Telephone-Type  Circuit*  (adopt* 
CCITT  V.29,  Supersedes  FIPS  135) 

FIPS  PUB 
167:1992 

Adopted 

(Approved) 

GPC 

NIST 

12000  and  14400  bp*  Four- Wire  Duplex  Modem*  for  Data 
Communication*  Use  on  Telephone-Type  Circuit* 

FIPS  PUB 
168:1992 

Adopted 

(Approved) 

GPC 

NIST 

Error  Correction  in  Modems  Employing  Asynchronous-to- 
Synduonous  Conversion 

FIPS  PUB 
169:1992 

Adopted 

(Approved) 

GPC 

NIST 

Data  Compression  in  Modem*  Employing  CCITT 
Recommendation  V.42  Error  Correction 

FIPS  PUB 
170:1992 

Adopted 

(Approved) 

GPC 

NIST 

Synchronous  Signaling  Rale*  Between  Data  Terminal  and 
Date  Communication  Equipment  (adopt*  ANSI  X3.1- 
1976) 

FIPS  PUB  22- 
1:1977 

Adopted 

(Approved) 

CPC 

PCMCIA 

PCMCIA  Release 
2.1  July  1993 

Adopted 

(Approved) 

IPC 

ITU-T 

Facsimile  Modem  Speed  Reduction*  and  Transaction  Tune 
-  Telephone  Network  and  ISDN  -  Quality  of  Service, 
Network  Management  and  Traffic  Engineering 

E.432  (1993) 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Standard  Multivalue  Logic  System  for  VHDL  Model 

Interoperability 

1164:1993 

Informational 

(Approved) 

GPC 

NIST 

2400  Bit*  per  Second  Two-Wire  Duplex  Modem*  for  Date 
Communication*  U*e  on  Telephone-Type  Circuits 
(Supersede*  FIPS  133^ed-Std- 1005 A) 

FIPS  PUB 
163:1992 

Informational 

(Approved) 

GPC 

NIST 

1200  bp*  2-Wire  Duplex  Modem*  for  Date 
Communications  use  on  Telephone-Type  Circuit*  (adopts 
CCITT  V.22.  Supersede*  FIPS  136) 

FIPS  PUB 
162:1992 

Informational 

(Approved) 

GPC 

NIST 

2400  Biu  per  Second  Four-Wire  Duplex  and  Two-Wire 
Half-Duplex  Modems  for  Date  Communications  Use  on 
Telephone-Type  Circuit*  (adopt*  CCITT  V.22  bi») 

FIPS  PUB 
164:1992 

Informational 

(Approved) 

GPC 

NIST 

4800  BiU  per  Second  Four-Wire  Duplex  and  Two-Wire 
Half- Duplex  Modems  for  Date  Communications  Use  on 
Telephone-Type  CircuiU  (Supersedes  FIPS  134-1) 

FIPS  PUB 
165:1992 

Informational 

(Approved) 

IPC 

ITU-T 

Telegraph  Modem  for  Subscriber  Lines  -  Telegraph 
Tnuumiision 

R.20  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

V.17  (1991) 

Informational 

(Approved) 

IPC 

ITU-T 

300  Biu  per  Second  Duplex  Modem  Standardized  for  Use 
m  the  General  Switched  Telephone  Network  -  Data 
Communication  over  the  Telephone  Network 

V.21  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

1200  Bits  per  Second  Duplex  Modem  Standardized  for  Use 
in  the  General  Switched  Telephone  Network  and  on  Poinl- 
to-Point  2- Wire  Leased  Telephone-Type  Circuits  -  Date 
Communication  Over  the  Telephone  Nelwoik 

V.22  (1989) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ITU-T 

2400  Bits  per  Second  Duplex  Modem  Using  the  Frequency 
Diviiion  Technique  Standardized  for  Use  on  the  General 
Switched  Telephone  Network  and  on  Point-to-Point  2-Wire 
Leased  Telephone- Type  Circuits  -  Data  Communication 
Over  the  Telephone  Network 

V.22  BIS  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

600/1200- Baud  Modem  Standardized  for  Uae  in  the 
General  Switched  Tekpbooe  Network  -  Data 
Communication  over  die  Telephone  Network 

V.23  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

2400  BiU  per  Second  Modem  Standardized  for  Uae  on  4- 
Wire  Leased  Telephone-Type  Circuits  •  Data 
Communication  over  die  Telephone  Network 

V.26  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

2400/1200  Bits  per  Second  Modem  Standardized  for  Use 
in  the  Gene  nil  Switched  Telephone  Network  -  Data 
Communication  over  die  Telephone  Network 

V.26  BIS  (1989) 

Informational 

(Approved) 

IPC 

rru-T 

2400  Bits  per  Second  Duplex  Modem  Using  the  Echo 
Cancellation  Technique  Standardized  for  Use  on  the 
General  Switched  Telephone  Network  and  on  Point-to- 
point  2-Wire  Leased  Telephone-Type  Circuits  -  Data 
Communication  over  the  Telephone  Netwoik 

V.26  TER  (1989) 

Informational 

(Approved) 

IPC 

rru-T 

4800  Bits  per  Second  Modem  with  Manual  Equalizer 
Standardized  for  Use  on  Leased  Telephone-Type  Circuits  - 
Data  Communication  over  the  Telephone 

V.27  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

4800/2400  BiU  per  Second  Modem  with  Automatic 
Equalizer  Standardized  for  Use  on  Leased  Telephone-Type 
CiiXuiU  •  Data  Communication  over  the  Telephone 
Netwoik 

V.27  BIS  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

4800/2400  BiU  per  Second  Modem  Standardized  for  Use 
in  the  General  Switched  Telephone  Network  -  Data 
Communication  over  the  Telephone  Network 

V.27  TER  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

9600  BiU  per  Second  Modem  Standardized  for  Use  on 
Point-to-Point  4- Wire  leased  Telephone  -  Type  Circuiu  - 
Data  Communication  over  the  Telephone  Network 

V.29 (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Duplex  Modem  Operating  at  Data  Signaling  Rates  of  up  to 
14400  bps  for  Use  on  the  General  Switched  Telephone 
Network  and  on  Leased  Point-to-Point  2-Wire  Telephone- 
Type  Circuiu 

V.32  BIS  (1991) 

Informational 

(Approved) 

IPC 

ITU-T 

14400  BiU  per  Second  Modem  Standardized  for  Use  on 
Point-to-Point  4- Wire  Leased  Telephone  -  Type  Circuiu  - 
Data  Communication  over  the  Telephone  Network 

V.33 (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Error-Correcting  Procedures  for  DCEa  Using 
Asynchronous-u>-Synchronous  Conversion  -  Data 
Communication  over  the  Telephone  Network 

V.42  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Data  Compression  Procedures  for  Data  Circuit 
Terminating  Equipment  (DCE)  Using  Error  Correction 
Procedures 

V.42  BIS  (1990) 

Informational 

(Approved) 

IPC 

ITU-T 

gfgK§§§Sg| 

V.32  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

EiTor-Correcung  Procedures  for  DCEs  Using 
Asynchronous-to-Synduonous  Conversion 

V.42.  Rev.  1 
(1993) 

Informational 

(Approved) 

IPC 

NATO 

Supreme  High  Frequency  (SHF)  Military  Satellite 
(M1LSATOOM)  Jam-Resistant  Modem 

STAN  AG  4376 

Informational 

(Draft) 

3.5.2.3.2  Alternative  specifications.  No  alternative  specifications  are  applicable. 

3.5.2.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  not  known. 

3.5.2.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  not  known. 
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3J  .133  Related  standards.  Magnetic  tape  storage  standards  are  related  to  physical  interface 
standards. 

33.23.6  Recommendations.  For  their  individual  areas  of  applicability,  the  adopted  FIPS  for 
physical  interface  are  recommended.  DOD  policy  requires  all  personal  computers  to  include  at 
least  one  PC  Card  (formerly  Personal  Computer  Memory  Card  Industries  Association 
(PCMCIA))  slot  to  allow  the  use  of  security  devices. 
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35.3  Optical  digital  technologies.  Optical  Digital  Technology  (ODT)  represents  technologies 
that  use  the  reflective  properties  of  light  and  an  optical  recording  surface  to  capture,  encode, 
decode,  and  store  data.  ODT  predominantly  encompasses  optical  media,  optical  drives,  and 
scanners. 

35.3.1  Optical  digital  technology.  This  optical  digital  technology  base  service  area 
concentrates  on  optical  scanning  and  image  quality,  excluding  opdcal  character  recognition. 

355.1.1  Standards.  Table  3.5-21  presents  standards  for  optical  digital  technology. 


TABLE  35-21  Optical  digital  technology  sUndards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI/AIIM 

Recommended  Practice  for  Quality  Control  of  Image 
Seamen 

MS44-1988 

(R1993) 

Adopted 

(Approved) 

NPC 

ANSI/AIIM 

Recommended  Practice  for  Monitoring  Image  Quality  of 
Roll  Microfilm  and  Microfiche  Seamen 

MS49-1993 

Adopted 

(Approved) 

NPC 

ANSI/AIIM 

Recommended  Practice  for  Monitoring  Image  Quality  of 
Aperture  Card  Film  Image  Scanner*  with  Scanner  Teat 
Target  Set 

MS 50-1994 

Adopted 

(Approved) 

NPC 

ANSI/AIIM 

MS 52-1991 

Adopted 

(Approved) 

GPC 

NIST 

FIPS  PUB 

157;  1989 

Adopted 

(Approved) 

NPC 

IEEE 

IEEE  Standard  Facsimile  Test  Chart 

167A:1987 

Adopted 

(Approved) 

NPC 

ANSI/AIIM 

Application  Programming  Interface  (API)  for  Scanners  in 
Document  Imaging  Systems 

MS61 

Informational 

(Draft) 

MS44  is  used  with  the  IEEE  Scanner  Test  Chart,  IEEE  167  A. 

FIPS  157  adopts  MS44. 

IEEE  167 A  is  also  known  as  AIIM  Scanner  Test  Chart  #2. 

35.3.1.2  Alternative  specifications.  No  alternative  specifications  are  known. 

35.3.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

35.3.1.4  Portability  caveats.  Portability  problems  of  the  existing  standards  are  unknown. 
35.3.15  Related  standards.  The  following  standards  are  related  to  optical  digital  technology: 

a.  ISO/IEC  93 16: 1995  -  Information  Technology  -  Small  Computer  Systems 
Interface  2 

b.  American  National  Standards  Institute  (ANSI)  X3. 131-1994:  Small  Computer 
System  Interface-2  (SCSI-2) 
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c.  NIST  FIPS  131,  Change  Notice  2: 1990  -  Information  Systems  -  Small  Computer 
System  Interface-2  (ANSI  X3.131-1986),  1987 

d.  ISO/IEC  12087  Information  Technology  —  Computer  graphics  and  image 
processing  -  Image  Processing  and  Interchange  (IPI)  -  Functional  Specification  - 
Part  1:1995:  Common  Architecture  for  Imaging;  Part  2:1994:  Programmer's 
imaging  kernel  system  application  programming  interface;  Part  3:1995:  Image 
Interchange  Facility  (UFO 

e.  ISO/IEC  13346: 1995,  Information  Technology  -  Volume  and  File  Structure  of 
Write-Once  and  Rewritable  Media  Using  Non-Sequential  Recording  for 
Information  Interchange,  Part  1:  General,  Part  2:  Volume  and  Boot  Block 
Recognition,  Part  3:  Volume  Structure,  Part  4:  File  Structure,  Part  5:  Record 
Structure.  (ECMA  167-1992) 

f.  ISO/IEC  DIS  12089: 1994,  Information  Technology  -  Computer  graphics  and 
image  processing  ~  Encoding  for  the  Image  Processing  and  Interchange  Standard 
(IPI)  -  Encoding  for  the  UF 

g.  ANSI/Association  for  Information  and  Image  Management  (AUM)  MS53-1993: 
Standard  Recommended  Practice  -  File  Format  for  Storage  and  Exchange  of 
Images  -  Bi-Level  Image  File  Format:  Part  1.  (NIST  FIPS  PUB  194:1995,  MIL- 
STD-188-196) 

h.  ISO/ANSI  9318-3: 1990,  Information  Technology  -  Intelligent  Peripheral 
Interface  -  Part  3:  Device  Generic  Command  Set  for  Magnetic  and  Optical  Disk 
Drives  (Revision  and  Redesignation  of  X3. 132: 1987) 

i.  ANSI  X3.201- 1992,  Information  Systems  -  Intelligent  Peripheral  Interface  - 
Enhanced  Physical  Level 

j.  MIL-STD-1 189A:  Standard  Department  of  Defense  Bar  Code  Symbology,  1989 

k.  ISO/IEC  10646-1:1993  (Amendments  1-5),  Information  Technology  -  Universal 
Multiple  Octet  Coded  Character  Set  (UCS)  -  Part  1 :  Architecture  and  Basic 
Multilingual  Place.  Standard  adopted  by  The  Frankfurt  Group  to  enhance  the 
Orange  Book  Compact  Disc  specifications.  ISO/IEC  10646  is  a  standard  for  using 
the  many  character  sets  of  the  world 

l.  ANSl/National  Information  Standards  Organization  (NISO)  Z39.2-1994: 
Information  Interchange  Format 

m.  ANSI/NISO  Z39.18-1995,  Scientific  and  Technical  Reports  -  Elements, 
Organization,  and  Design 
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n.  ANSI/NISO  Z39.50-1995:  Information  Retrieval  Application  Service  Definition 
and  Protocol  Specification  for  Open  Systems  Interconnection 

o.  ANSI/NISO  Z39.58- 1992:  Common  Command  Language  for  Online  Interactive 
Information  Retrieval 

p.  AIIM  TR2- 1992,  Glossary  of  Imaging  Technology 

q.  ANSI/AIIM  TR15,  Planning  Considerations,  Including  Preparation  of  Documents 
for  Image  Capture  Systems 

r.  ANSI/AIIM  MS59-1996,  Media  Error  Monitoring  and  Reporting  Techniques  for 
Verification  of  the  Stored  Data  on  Optical  Digital  Data  Disks. 

s.  ANSI/AIIM  TR41-Proposed,  Technical  Report  on  Optical  Storage  Standards. 

3.5.3. 1.6  Recommendations.  Evaluate  and  select  the  adopted  standards  appropriate  for  the 
organization's  application. 
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3  J 3 2  Optical  character  recognition.  Optical  character  recognition  (OCR)  standards  define 
optically  scanning  a  document  to  identify  the  text  it  contains  and  convert  it  from  bitmaps  to 
characters. 

3.5.3.2.1  Standards.  Table  3.5-22  presents  standards  for  optical  character  recognition. 


TABLE  3.5-22  Optical  character  recognition  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Character  Set*  for  Optical  Climcler  Recognition  (OCR) 
(adopts  ANSI  X3.2-197Q/R1976,  X3.17-1981/R1989,  . 
X3.49-1975/R1982.  2989) 

FIPS  PUB  32- 
1:1982 

Informational 

(Approved) 

GPC 

NIST 

Character  Set  for  Handprinting  (adopts  ANSI  X3.4S-I982 

FIPS  PUB  33- 
1:1984 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Optical  Character  Recognition  Form* 

FIPS  PUB  40:1976 

InfoimationaJ 

(Approved) 

GPC 

NIST 

FIPS  PUB  85:1980 

Informational 

(Approved) 

GPC 

NIST 

Optical  Character  Recognition  (OCR)  Character 
Positioning  (adopt*  ANSI  X3.93M-I981) 

FIPS  PUB  89:1981 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  90:1983 

Informational 

(Approved) 

GPC 

NIST 

Optical  Character  Recognition  (OCR)  -  Dot  Matrix 
Character  SeU  for  OCR-MA  (adopt*  ANSI  X3.1 1 1-1986) 

FIPS  PUB 
129:1987 

Informational 

(Approved) 

[PC 

ISO 

Alphanumeric  Character  Set*  for  Optical  Recognition  - 
Part  1:  Character  Set  OCR -A  -  Shape*  and  Dim  on*  ion*  of 
ihe  Printed  Image;  (Amendment  Slip- 1978) 

1073-1:1976 

Informational 

(Approved) 

IPC 

ISO 

1073-2:1976 

Informational 

(Approved) 

IPC 

ISO 

Coding  Machine  Readable  Character*  (MICR  and  OCR) 

2033:1983 

Informational 

(Approved) 

NPC 

ANSI 

Character  Set  for  Optical  Character  Recognition  (OCR-A) 

X3.  17-1981 
(R 1989) 

Informational 

(Approved) 

NPC 

ANSI 

Character  Set  for  Optical  Character  Recognition  (OCR-B) 

X3.  49-1975 
(R 1 989) 

Informational 

(Approved) 

NPC 

ANSI 

Optical  Character  Recognition  (OCR)  Ink* 

X3.  86-1980 
(R1993) 

Informational 

(Approved) 

NPC 

ANSI 

Optical  Character  Recognition  (OCR)  Character 

Portioning 

X3. 93M-I981 
(R1989) 

Informational 

(Approved) 

NPC 

ANSI 

Optical  Character  Recognition  (OCR)  -  Guideline*  for 
OCR  Print  Quality 

X3. 99-1983 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Optical  Character  Recognition  (OCR)  -  Matrix  Character 
Seu  for  OCR-MA 

X3, 1 11-1986 
(RI992) 

Informational 

(Approved) 

NPC 

ANSI 

Optical  Character  Recognition  (OCR)  -  Matrix  Character 
Set*  for  OCR- MB 

X3.209 

Informational 

(Approved) 

IPC 

ECMA 

Alphanumeric  Character  Set  OCR-B  for  Optical 
Recognition 

11  (1976) 

Informational 

(Approved) 

IPC 

ECMA 

Nominal  Character  Dimemiom  of  the  Numeric  OCR-A 
Font 

8(1977) 

Informational 

(Canceled) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

tPC 

ECMA 

Character  Petitioning  on  OCR  Journal  Tape 

21 (1969) 

Informational 

(Canceled) 

[PC 

ECMA 

OCR-B  Sutau  for  Numeric  Applications 

30(1976) 

Informational 

(Canceled) 

IPC 

ECMA 

Implementation  of  the  Nimeric  OCR- A  Foot  with  9X9 
Matrix  Printen 

51  (1977) 

Informational 

(Canceled) 

3 £32.1  Alternative  specifications.  No  other  specifications  are  available. 

3.S.3.2  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.3.2.4  Portability  caveats.  Portability  problems  are  unknown  at  this  time. 

3.5.3.2.5  Related  standards.  ODT  is  most  beneficial  in  application  of  mass  storage  which  is 
usually  necessary  with  scanned  documents.  Raster  data  interchange  standards,  imaging  standards, 
and  compression  standards  are  related  to  ODT. 

3.5.3.2.6  Recommendations.  The  FIPS  for  OCR  are  preferred. 


April  7,  1997 


3.5-37 


Version  3. 1 


3.5.4  Office  automation  document  interchange.  The  following  base  service  areas  deal  with 
data  formatting  and  exchange  standards  for  different  types  of  documents  in  an  office  automation 
environment 


3.5.4. 1  Document  interchange.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  12, 
Multimedia.)  Document  interchange  standards  allow  the  transfer  of  formatted  documents  across  a 
network  so  they  can  be  reproduced  exactly  and  worked  on  at  their  destinations. 

3.5.4.1.1  Standards.  Table  3.5-23  presents  standards  for  document  interchange. 


TABLE  3.5-23  Document  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Standard  Generalized  Markup  Language  (SGML) 
(Amendment  1  - 1988)  (Adopted  by  FIPS  PUB  152:1989) 

8179:1986 

Mandated 

(Approved) 

CPC 

IETF 

HyperText  Markup  Language  (HTML)  v.2.0 

RFC  1866:1995 

Mandated 

(Approved) 

OPC 

DOD 

Markup  Requirement!  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  text  (baaed  on 
ISO  8879) 

hflL-PRF-28001 

Informational 

(Approved) 

IPC 

ISO/EC 

Distributed  Office  Applications  Model  (DOAM),  Part  1 : 

General  Model 

10031-1:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Distributed  Office  Applications  Model  (DOAM),  Part  2: 
Distinguished  Object  Reference  and  Associated  Procedures 

10031-2:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Document  Filing  and  Retrieval  (DFR),  Part  1 :  Abstract 
Service  Definition  and  Procedures  (corrigendum  1-1994, 
corrigendum  2-  1994,  corrigendum  3-1994) 

10166-1:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Document  Filing  and  Retrieval  (DFR),  Part  2:  Protocol 
Specification  (corrigendum  1-1994) 

10166-2:1991 

Informational 

(Approved) 

IPC 

ISO 

Text  and  Office  Systems  -  Referenced  Data  Transfer  -  Part 

1:  Abstract  Service  Definition 

10740-1 

Informational 

(Approved) 

IPC 

ISO 

10740-2 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  •  Services 
and  Protocols-  Introduction  and  General  Principles 

T.431  (1992) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  •  Service 
Definition 

T.432  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  •  Protocol 
Specification 

T.433  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  - 
Operational  Structure 

T.441  (1989) 

Informational 

(Approved) 

NPC 

ANSI 

Text  Information  Interchange  in  Page  Image  Format  (PIF) 

X3.  98-1983 

Informational 

(Approved) 

IPC 

ISO 

Standard  Generalized  Markup  Language  (SGML) 
Document  Interchange  Format  Support  Facilities  (SDIF) 

9069:1988 

Informational 

(Approved) 

IPC 

ISO/IEC 

Documenlation  Style  Semantics  and  Specification 
Language  (DSSSL) 

10179:1995 

Informational 

(Approved) 

(TN-C 

AT&T 

TROFF  -  Markup  Language 

Unix  BSD  4.3 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPN-C 

Microsoft 

Ridt  Text  Format  (RTF) 

RTFTedi.  Mtnuli 

Informational 

(Approved) 

CPN-C 

Adobe 

PostScript  Type  I  -  Outline* 

PS  Tech.  Manuals 

Informational 

(Approved) 

CPN-C 

Adobe 

Portable  Document  Format  (PDF) 

PDF 

Informational 

(Approved) 

CPC 

IETF 

HyperText  Markup  Language  (HTML) 

HTML  v.3.2 

Emerging 

(Draft) 

OPC 

DOD 

MIL-M-2800IB  of 
6/26/1993 

Informational 

(Superseded 

(CALS)) 

3.5. 4. 1.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  ANSI/NISO  Z39.59- 1988  (to  represent  the  logical  structure  of  books  and  articles) 

b.  The  Association  of  American  Publishers  (AAP),  the  Text  Encoding  Initiative 
(TEI),  and  the  DOD  Continuous  Acquisition  and  Life  Cycle  Support  (CALS) 
program  have  designed  alternate  nonproprietary  architectures  with  SGML 
encodings 

c.  Microsoft's  Dynamic  Data  Exchange  (DDE) 

d.  Microsoft's  Dynamic  Link  Libraries 

e.  ANSI/NISO  Z39.2-1994:  Information  Interchange  Format 

f.  ANSI/NISO  Z39. 1 8-1995:  Scientific  and  Technical  Reports  -  Elements, 
Organization,  and  Design 

g.  ANSI/NISO  Z39.50- 1992:  Information  Retrieval  Application  Service  Definition 
and  Protocol  Specification  for  Open  Systems  Interconnection 

h.  ANSI/NISO  Z39.59-1992:  Common  Command  Language  for  Online  Interactive 
Information  Retrieval 

3.5.4.1.3  Standards  deficiencies.  There  is  very  little  standardization  of  font  names  when  handling 
fonts  represented  by  tagged-text  data  types.  However,  many  systems  are  attempting  font 
substitution,  that  is,  replacing  a  specified  font  with  one  that  is  similar,  such  as  substituting 
TrueType  Arial  for  PostScript  Helvetica.  Not  all  tagged  text  systems  are  able  to  specify  colored 
text. 
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The  following  are  recognized  gaps  in  the  Office  Document  Architecture  (ODA)/  Office  Document 
Interchange  Format  (ODIF)  standards: 

a.  Revision  collection,  status,  rationale,  and  author  information 

b.  Document  annotations 

c.  Automatic  content  generation  of  listings  such  as  table  of  contents,  lists  of  figures, 
indexes,  glossaries,  and  cross-references 

d.  Business  charting,  including  the  ability  to  derive  business  graphics  from  tabular, 
spreadsheet,  or  other  data  in  the  document  or  referenced  by  the  document;  the 
ability  to  derive  part  of  a  document  from  external  business  graphics,  and  the  ability 
to  include  a  business  graphic  in  a  document  in  such  a  way  that  the  processing 
specific  to  business  graphics  can  be  performed  by  the  recipient  of  a  document 

e.  Data  in  documents,  such  as  spreadsheets 

f.  Exchange  of  documents  based  on  hypertext 

g.  Exchange  of  documents  that  include  voice  and  audio  information  (Hyper  ODA) 

3.5.4, 1,4  Portability  caveats.  At  present,  portability  using  ODA/ODIF  is  limited,  because  it  is 
not  in  widespread  use  or  widely  available,  although  SGML  is  widely  available. 

3J5.4.1.5  Related  standards.  The  following  standards  are  related  to  document  exchange: 

a.  ISO  8824:1987  and  ISO  8825:1987  -  ASN.l/BER 

b.  SGML  for  documents  that  are  not  predefined 

c.  TeX  by  Donald  Knuth  of  MIT  and  LaTeX  macros  are  widely  used  for  typesetting, 
especially  for  documents  that  include  mathematics 

3.5.4. 1.6  Recommendations.  In  keeping  with  the  ongoing  shift  from  literal  page  appearance  to 
electronic  transfer  of  document  content  (as  exemplified  by  the  electronic  commerce  and  CALS 
programs)  we  recommend  the  use  of  SGML  for  document  interchange.  Alternative  standards  - 
Adherence  to  CALS  specifications  and  standards  should  be  maintained  to  the  maximum  extent 
possible,  as  use  of  CALS  provides  maximum  interoperability.  In  the  event  that  a  CALS  standard 
cannot  convey  the  technical  information  of  a  particular  application,  only  then  is  the  use  of  a  non- 
CALS  standard  justified.  On  March  25-26,  1993,  the  Defense  Information  Systems  Agency 
(DISA)  convened  a  Document  Interchange  Symposium.  The  symposium  featured  a  panel  of 
ODA  and  SGML  experts  to  deliberate  on  SGML/ODA  issues.  The  panel  reached  the  following 
conclusions: 
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a.  SGML  has  been  adopted  by  a  wide  range  of  government  and  private  industry 
initiatives  for  document  interchange. 

b.  Few  commercially  viable  ODA  products  are  found  in  the  U.S.  marketplace. 

c.  Distinctions  between  office  and  publishing  documents  are  diminishing  (making  the 
need  for  unique  office  document  architectures  less  acute). 

d.  SGML  has  been  adopted  by  the  publishing  community. 

In  addition  to  the  panel's  conclusions,  it  should  be  noted  that  NIST  has  decided  not  to  develop  a 
FIPS  for  ODA.  The  DOD  SGML  standard  (MIL-PRF-28001)  is  based  on  ISO  8879.  MIL- 
HDBK-28001  for  SGML  is  being  developed. 

For  documents  intended  for  distribution  on  the  Internet,  particularly  the  World  Wide  Web,  HTML 
should  be  used.  HTML  is  a  document  type  definition  (DTP''  -f  SGML  for  Internet  documents. 

Adobe  PDF  is  being  used  frequently  in  DOD  for  formatti  .v,  T  v.n<;or:v;  ■  »•;  i-  .  .;v'-;ions  are  not 
required.  However,  PDF  suffers  by  the  fact  that  it  has  not  yet  been  endorsed  uy 
consensus  standards  body.  Efforts  need  to  be  taken  to  move  PDF  from  the  de  facto,  pr-v  riei.iry. 
realm  to  be  an  open  standard. 
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3 .5.4.2  Spreadsheet  data  interchange.  Spreadsheet  data  interchange  is  the  exchange  of  tabular 
alphanumeric  data  (i.e.,  data  found  in  spreadsheets). 

3.5.4.2.1  Standards.  Tabic  3.5-24  presen  _  standards  for  spreadsheet  data  interchange. 


TABLE  3.5-24  Spreadsheet  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ni, 

\PC 

ISO/TEC 

Open  Document  Architecture  (ODA)  and  Interchange 
Format!  Tabular  Structure*  and  Tabular  Layout 

8613»ll:1996 

Informational 

(Approved) 

3J.4.2.2  Alternative  specifications.  The  follow  de  facto  specifications  are  also  available: 

a.  SoftArts,  Data  Interchange  Format  (DIF)  for  exchanging  data  between  tables 

b.  Microsoft,  XLS  spreadsheet  format 

c.  Lotus  Development,  WK4,  WK3,  WK1,  and  VVKS  spreadsheet  formats 

3.S.4.2.3  Standards  deficiencies.  The  de  facto  DIF  and  the  WK3,  WK1,  and  WKS  formats 
mostly  allow  the  contents  of  spreadsheet  cells  to  be  imported  into  a  document,  separated  by  tabs. 
Most  major  spreadsheet  products  allow  the  import  and  export  of  XLS  and  WKx  data  values  and 
common  formulas.  Unless  the  vendor  of  a  document  creation  product  has  made  a  specific  custom 
interface  to  the  spreadsheet  package  whose  data  is  to  be  imported,  all  lines,  shading,  graphics,  and 
many  other  spreadsheet  features  are  lost  No  standards,  de  facto  or  otherwise,  exist  for  arranging, 
interpreting,  or  otherwise  processing  the  spreadsheet  after  it  has  been  imported  into  a  new 
document. 

3.5A2.4  Portability  caveats.  The  de  facto  DIF  standard  and  WK3,  WK1,  and  WKS  formats 
provide  limited  portability  and  interoperability.  Although  they  allow  a  spreadsheet's  cell  contents 
to  be  interchanged  and  imported  into  another  spreadsheet  separated  by  tabs,  depending  on  the 
packages  or  the  cell  contents,  the  data  may  be  interchanged  as  a  stream  of  numbers  or  strings, 
without  clear  beginnings  or  endings. 

3.5.4.2.5  Related  standards.  The  following  standards  are  related  to  spreadsheet  data  exchange 
or  spreadsheet  data  exchange  standards: 

a.  ISO  8613:  ODA/OD1F. 

b.  ISO  8879:  SGML. 

3.5.4.2.6  Recommendations.  If  a  particular  agency  has  many  existing  spreadsheet  packages,  the 
quest  for  portability,  interoperability,  and  data  interchange  will  make  it  advisable  to  require  an 
open  interface  to  access  each  of  these  existing  systems,  rather  than  having  a  common  format  such 
as  "DIF." 
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3 .5.4.3  Custom  definition  of  document  types.  These  standards  provide  the  ability  to  custom- 
define  a  document  type  when  predefined  document  types  are  not  applicable. 

3.5.4.3.1  Standards.  Table  3.5-25  presents  standards  for  custom  definition  of  document  types. 


TABLE  3.5-25  Custom  definition  of  document  types  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

[PC 

ISO 

Standard  Generalized  Markup  L any i age  (SGML) 
(Amendment  1  -  1988)  (Adopted  by  FIPS  PUB  152:1989) 

8879:1986 

Mandated 

(Approved) 

IPC 

ISO 

Standard  Generalized  Markup  Language  (SGML) 
Document  Interchange  Format  Support  Fadlibe*  (SDIF) 

9069:1918 

Informational 

(Approved) 

IPC 

ISO/IEC 

Standard  Generalized  Markup  Language  (SGML)  Support 
Facilitiea:  Registration  Procedure*  for  Public  Text  Owner 
Identifier* 

9070:1991 

Informational 

(Approved) 

IPC 

ISO 

SGML  Support  Facilities  •  Technique*  for  Using  SGML 

TR  9573:1988 

Informational 

(Approved) 

IPC 

ISO/IEC 

TR  9573-13:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

SGML  and  Text-Entry  Systems  •  Guidelines  for  SGML 
Syntax- Directed  Editing  Systems 

TR  10037:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Hypermedia/Time-Based  Structuring  Language  (HyTiroe) 

10744:1992 

Informational 

(Approved) 

NPC 

ANSI/NISO 

Electronic  Manuscript  Preparation  and  Markup 

Z39.59:1988 

Informational 

(Approved) 

NPC 

ANSI 

Conformance  Testing  for  Standard  Generalized  Markup 
Language  (SGML)  Systems 

X3. 190- 1992 

Informational 

(Approved) 

GPC 

DOD 

MIL-PRF-28001 

Informational 

(Approved) 

IPC 

iSO/IEC 

Documentation  Style  Semantics  and  Specification 
Language  (DSSSL) 

10179:1995 

Informational 

(Approved) 

GPC 

DOD 

Markup  Require*'  wnU  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  text  (based  on 
ISO  8879) 

MIL-M-28001B  of 
6/26/1993 

Informational 
(Superceded 
(CALS)) _ 

IPC 

ISO/IEC 

Text  and  Office  Systems  •  Conformance  Testing  for 
Standard  Generalized  Markup  Language  (SGML)  Systems 

13673:1993 

Informational 

(Draft) 

3.S.4.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  ISO  8824:1987:  ASN.l 

b.  The  AAP,  the  TEi,  and  the  DOD  CALS  program  have  designed  alternate, 
nonproprietary  architectures  with  SGML  encodings. 

3.S.4.3  _3  Standards  deficiencies.  SGML  docs  not  deal  with  the  meaning  of  the  markup,  so 
additional  standards  are  needed.  Markup  consists  of  the  common  sets  of  document  formatting 
codes  used  in  classes  of  document  types. 
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Technical  manuals  may  use  a  different  markup  from  management  guideline  documents  to 
accommodate  the  audience,  content,  and  publishing  layout  styles  commonly  used  for  each 
document  type.  Since  SGML  does  not  deal  with  the  markup's  meaning,  it  does  not  specify  what 
to  do  after  the  document  has  been  processed  by  a  program  that  recognizes  SGML. 

SGML  does  not  deal  with  hypermedia/time-based  document  interchange,  although  standards  in 
that  area  are  being  developed. 

SGML  does  not  use  object-oriented  methods,  although  such  work  is  underway  in  the 
Miildmedia/Hypermedia  Experts  Group  (MHEG). 

3.S.4.3.4  Portability  caveats.  A  lot  of  disagreement  still  exists  on  the  particular  markup  to  be 
employed  in  document  types.  This  can  result  in  incompatible  and  misinterpreted  markups. 

Use  SGML  in  conjunction  with  selected,  stable,  draft  specifications  from  the  MHEG  to  handle 
multimedia  objects,  as  well  as  other  objects. 

3S.4.3S  Related  standards.  The  following  standards  are  related  to  custom  definition  of 
document  types  and  definition  standards: 

a.  ISO  8613:  ODA/ODIF  Parts  1-10  and  amendments  and  addenda.  ODA  Part  5 
specifies  a  method  of  representation  and  interchange  using  the  Office  Document 
Language  and  SDIF.  ODL  may  be  used  to  represent  a  document  structure  in 
accordance  with  ODA  in  SGML. 

b.  ISO  DIS  10180:  SPDL 

c.  ISO  DIS  10179:  DSSSL,  an  application  of  SGML;  includes  a  document 
architecture  for  typographic  presentation  style. 

d.  ISO  10744/ANSI  X3V1.8M  (Project  749-D):  Hypermedia/Time-based  Structuring 
Language  (HyTime).  HyTime,  a  notation  to  describe  hypermedia,  is  an  extension 
of  SGML  to  deal  with  hypermedia/time-based  document  interchange. 

e.  ISO  10031:1990:  Distributed  Office  Applications  Model  (DOAM),  Parts  1-2.  ISO 
10031  provides  guidelines  for  defining  Distributed  Office  Application  objects,  such 
as  documents,  object  attributes,  and  abstract  operations,  for  use  in  a  client-server 
environment. 

f.  MIL-STD-1840B  (1 1/3/1992):  Automated  Interchange  of  Technical  Information 
(Life  cycle  logistics  support  for  weapon  systems) 

3.S.4.3.6  Recommendations.  The  following  two  ISO  technical  reports  include  supportive  SGML 
tips  and  guidelines.  Their  use  in  learning  about  SGML  and  to  achieve  portability  is  valuable. 
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Use  specifications,  such  as  Electronic  Manuscript  Preparation  and  Markup  (EMPM)  or  ODA,  to 
determine  the  markup's  meaning  in  order  to  decide  what  to  do  after  the  document  has  been 
processed  by  a  program  that  recognizes  SGML. 

a.  ISO  Technical  Report  (TR)  9573:  SGML  Support  Facilities:  Techniques  for  Using 
SGML 

b.  ISO  TR  10037:  SGML  and  Text-Entry  Systems-Guidelines  for  SGML  Syntax- 
Directed  Editing  Systems 

SGML  contains  multiple  languages  and  applications,  each  of  which  must  be  specified  explicitly  in 
a  procurement. 

SGML  has  several  advantages.  It  is  used  by  CALS,  more  commercial  products  are  available  for  it 
than  for  ODA/ODIF/ODL,  it  is  human-readable,  preserves  user  file  divisions,  and  is  extensible  to 
other  architectures.  Moreover,  it  transcends  ordinary  office  documents  and  supports  graphics  and 
multimedia  now. 

However,  CALS  uses  the  more  restrictive  SGML  standard  (MIL-PRF-28001),  minimizes  markup, 
and  uses  fewer  SGML  features  to  provide  a  "DOD  profile"  of  SGML.  MIL-HDBK-28001  for 
SGML  is  being  developed  to  aid  users  of  the  standard. 
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3 .5.4.4  Bibliographic  system  text  retrieval.  Bibliographic  system  text  retrieval  standards 
specify  the  representation  of  the  logical  structure  of  books,  articles,  and  serial  publications  and  a 
common  command  language  for  managing  bibliographic  systems. 

3.S.4.4.1  Standards.  Table  3.S-26  presents  standards  for  bibliographic  system  text  retrieval. 


TABLE  3.5-26  Bibliographic  system  text  retrieval  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

B339I 

BuBSSBl 

NPC 

ANSI/NISO 

Information  Retrieval  Service  Definition  and  Protocol 
Specification  for  Open  Systems  Interconnection 

Z39.50:1995 

Informational 

(Approved) 

NPC 

ANSI/NISO 

Common  Command  Language  for  On-Line  Interactive 
Information  Retrieval 

Z39.58M992 

Informational 

(Approved) 

IPC 

tSO/IEC 

OSl  Search  and  Retrieve  Application  Service  Definition 

10162:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Search  and  Retrieve  Application  Protocol 
Specification  Part  1 :  Protocol  Specification 

10163-1:1993 

Informational 

(Approved) 

IPC 

ISO 

Commands  for  Interactive  Text  Searching 

8777:1993 

Informational 

(Approved) 

GPC 

Commerce 

CD-RDx  (A  query  standard  for  computer-based  retrieval  of 
CD-ROM  publication) 

CD-RDx 

Informational 

(TBP) 

NPC 

ANSI 

Structured  Pile  Query  Language  (SPQL)  (A  query 
language,  based  on  SQL,  with  extensions  to  support  full 
text,  and  using  SGML  Document  Type  Definitions  to 
define  metainformation  about  a  table  or  document) 

X3H2- Designated 
number  to  be 
assigned 

Informational 

(Draft) 

CPC 

ATA 

Structured  File  Query  Language  (SFQL)  (A  query 
language,  based  on  SQL,  with  extensions  to  support  full 
text,  and  using  SGML  Document  Type  Definitions  to 
define  metainformation  about  a  table  or  document) 

SFQL 

informational 

(Formative) 

3.5.4.4.2  Alternative  specifications.  The  allowing  specifications  are  also  available: 

a.  Thinking  Machines,  Inc.'s,  Wide-Area  Information  Server  (WAIS),  a  protocol  for 
transmitting  query  and  retrieval  information,  which  has  been  adopted  by  a  number 
of  major  vendors  and  runs  on  a  wide  variety  of  platforms  and  networks.  (NOTE: 
WAIS  is  an  extension  to  the  Z39.50  standard  to  allow  discrete  portions  of 
documents  to  be  retrieved.  WAIS  is  currently  running  in  about  80  sites.) 

b.  Information  Dimensions  Inc.'s  OpenAPI,  a  callable  API,  which  is  a  low  level 
toolkit  interface  for  developers  to  use  in  building  Graphical  User  Interface  (GUI)- 
based  text  retrieval  applications  that  run  on  MS  Windows,  MAC,  VMS,  and  UNIX 
desktops  and  connect  to  servers,  over  a  variety  of  transports. 

3.5.4.4.3  Standards  deficiencies.  The  CD-RDx  is  considered  by  many  in  the  government  to  be 
less  robust  and  reliable  than  the  Structured  File  Query  Language  (SFQL),  which  is  more  accepted 
and  will  become  an  IEEE  standard, 
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35.4.4.4  Portability  caveats.  The  standards  developed  by  NISO  are  in  widespread  use  in 
libraries  and  bibliographic  systems,  but  are  not  compatible  with  the  more  widely  accepted  DFR 
and  DTAM  standards  in  the  general  office  and  document  world. 

35.4.45  Related  standards.  The  following  standards  are  related  to  bibliographic  system  text 
retrieval  or  retrieval  standards: 

a.  ISO  10166:  Document  File  and  Retrieval  (DFR) 

b.  ITU-T  T.43 1 ,  T.432,  T.433,  and  T.44 1 :  Document  Transfer  and  Manipulation 
(DTAM) 

35.4.4.6  Recommendations.  The  ISO  text/data  retrieval  protocol  is  recommended  for  OSI 
applications.  For  library  applications  in  client-server  environments  ANSI/NISO  Z39.50-1988  is 
recommended  in  conjunction  with  the  command  language  in  ANSI/NISO  Z39.S8-1992. 
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3.5.4  J  Electronic  forms.  (This  BSA  appears  in  part  3,  User  Interface,  part  4,  Data 
Management,  and  part  5,  Data  Interchange.)  These  standards  specify  the  functional  interface 
requirements,  transfer  of  various  fields  and  the  interface  between  programming  languages  and 
form  filling  applications  for  use  on  a  terminal  display. 

3.5.4.5.1  Standards.  Table  3.5-27  presents  standards  for  electronic  forms. 


TABLE  3.5-27  Electronic  forms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

DOD  Standardized  Electronic  Form*  Requirement* 

JIEO-E-2300 

Adopted 

(Approved) 

1PC 

ISO/ffiC 

Form*  Interface  Management  System  (FIMS) 

11730:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Open  System  Interconnection  Profile  (GOSIP 
2):  Virtual  Terminal  Form*  Clasi  Profile 

FIPS  PUB  146. 
1:1991 

Informational 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Utilities,  Iiiue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  Unix  Specification:  XA^pen  Curse*,  Issue  4  (part  of 
XPG4) 

C437  (2/95) 

Emerging 

(Approved) 

GPC 

DOD 

DOD  Forms  Management  Program  Procedures  Manual 

DOD7750.7-M 

Informational 

(Approved) 

CPN-C 

Numerout 

vendor* 

Query  by  Forms 

Query  by  Forms 

Informational 

(Approved) 

IPC 

ISO/ffiC 

OSI  Virtual  Terminal  Basic  Clast  Service,  Amendment  2: 
Additional  Functional  Units  (forms  capability) 

9040:1990  DAM  2 

Informational 

(Draft) 

IPC 

ISO/ffiC 

OSI  Virtual  Terminal  (VT)  Basic  Class  Protocol,  Part  1, 
Amendment  2:  Additional  Functional  Units  (Forms 
Capability) 

9041-1:1990  DAM 

2 

Informational 

(Draft) 

CPC 

X/Open 

Internationalized  Terminal  Interfaces  (XCURSES),  Issue  4 

S422  (4/94) 

Informational 

(Superseded) 

3J.4.5.2  Alternative  specifications.  The  Berkeley  Software  Distribution  (BSD)  4.2/4.3  UUNIX 
Curses  are  also  available. 

3.5.4.S.3  Standards  deficiencies.  The  X/Open  Portability  Guide  4  (XPG4)  Curses  is  based  on 
the  System  V  Interface  Definition  (SVID)  Issue  2  Curses  version,  which  does  not  include  the 
SVID's  forms  and  .tenu  libraries. 

Forms  Class  Virtual  Terminal  has  bindings  in  C  only. 

DOD  has  developed  a  specification  for  electronic  forms  (Joint  Interoperability  and  Engineering 
Organization  (JIEO)-E-2300).  It  defines  the  minimum  operational  requirements  for  electronic 
forms  software  and  mandates  an  interchange  file  format  based  on  Forms  Interface  Management 
System  (FIMS). 
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35.4.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

35.4.55  Related  standards.  The  Forms  Class  Virtual  Terminal  requires  the  Synchronous  mode 
(S-mode)  of  operation  and  specifies  simple  delivery  control.  The  following  standards  are  related 
to  forms  query  and  management: 

a.  ISO  9075:  SQL 

b.  ANSI  X3.135-1992:  SQL2 

c.  NIST  FIPS  127-2:  SQL 

d.  NIST  FIPS  193:  SQL  Environments 

35.45.6  Recommendations.  The  recommended  standard  is  JIEO-E-2300,  For  User  Interface, 
FIMS  should  be  considered.  For  Data  Management  make  sure  the  forms  management  systems 
are  compatible  with  FIPS  127-2  SQL.  Database  forms  management  systems  should  be  integrated 
with  the  SQL  database  language  and  formats  set  forth  in  FIPS  PUB  127-2. 
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3.5.5  Technical  data  interchange.  The  technical  data  interchange  mid-level  service  area 
includes  vector  graphics,  product  data,  and  electronic  commerce  standards  areas. 

3.5.5. 1  Product  data  interchange.  These  standards  establish  data  formats  for  interchanging 
product  description  data.  These  data  include  not  only  a  graphical  depiction,  but  also 
manufacturing  process  information  such  as  materials  and  surface  finishing. 

3.5.5.1.1  Standards.  Table  3.5-28  presents  standards  for  product  data  interchange. 


TABLE  3.5-28  Product  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI/US  PRO 

Digital  Representation  for  Communication  of  Product 
Definition  Dau  (revision  and  redesignation  of 
ANSI/ASME  Y14.26M-1989)  (Formerly  IGES) 

ANSI/US  PRO/ 
IPO  100-1996 

Adopted 

(Approved) 

GPC 

NIST 

Initial  Graph  tea  Exchange  Specification  (IGES)  (adopts 
ASME/ANSI  Y14.26M-1989)  (IGES  ver.  4) 

FIPS  PUB 
177:1992 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  (be  Exchange  of  Product  Model  Data  (STEP), 
Part  1 :  Overview  and  Fundamental  Principle*  (formerly 
Product  Data  Exchange  Specification  (PDES)) 

10303-1:1994 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  11;  Hie  EXPRESS  Language  Reference  Manual 
(formerly  PDES) 

10303-11:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  21:  Implementation  Method*:  Clear  Text  Encoding  of 
the  Exchange  Structure 

10303-21:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  31:  Conformance  Teiting  Methodology /Framework : 
General  Concept* 

10303-31:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  41:  Integrated  Generic  Reiource*:  Fundamental-  of 
Product  Detcription  and  Support 

10303-41:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  42:  Integrated  Generic  Resource*;  Geometric  and 
Topological  Representation 

10303-42:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  43:  Integrated  Generic  Resource*:  Representation 
Structure* 

10303-43:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  44:  Integrated  Generic  Resource*:  Product  Structure 
Configuration 

10303-44:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  101:  Integrated  Application  Resource!;  Draughting 

10303-101:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  ..or  the  Exchange  of  Product  Model  Data  (STEP), 
Part  201 :  Application  Protocol:  Explicit  Draughting 

10303-201:1994 

Adopted 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  203:  Application  Protocol:  Configuration  Controlled 
Design 

10303-203:1994 

Adopted 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocol* 

MIL-PRF-28000 

Adopted 

(Approved) 

GPC 

IX)  D 

Automated  Interchange  of  Technical  Information  (Life 
cycle  logiitic  lupport  of  weapon  systems) 

MIL-STD-1840B 
of  11/3/1992 

Adopted 

(Approved) 

GPC 

DOD 

Requirements  for  Railer  Graphic*  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

M1L-PRF-28002 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI/US  PRO 

US  PRO/IPO*  100 
(Nov  1993) 

Informational 

(Approved) 

IPC 

1SO/IEC 

Put  Libruied,  About  10  Puts  in  Prof  real 

135&4-XX  wort  in 
TC184/SC04 

Informational 

(Draft) 

GPC 

NIST 

Initial  Graphic*  Eichange  Specification  (IGES);  v.  5.2  OR 

6.0 

FIPS  PUB  177-1 
(future) 

Informational 

(Formative) 

GPC 

DOD 

DifiUl  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subaeti  and  IGES  Application 
Protocol! 

MJL-D48000AO) 
at  12/14/92 

Informational 

(Superseded) 

GPC 

DOD 

Requirement*  for  Ruter  Graphic*  Representation  in  Binary 
Format  (Group  4  Rafter  Scanned  Image*) 

MIL-R-28002B(1) 
of  9/20/1993 

Informational 

(Superseded) 

NPC 

ANSI/ASME 

Digital  Repreaentation  for  Communication  of  Product 
Definition  Data 

Y14.26M:1989 

Informational 

(Superseded) 

3.5.5.1.2  Alternative  specifications.  Standard  for  the  Exchange  of  Product  Model  Data  (STEP) 
is  being  developed  as  an  advanced  alternative  to  Initial  Graphics  Exchange  Specifications  (IGES). 

3.5.5. 1.3  Standards  deficiencies.  IGES  does  not  cover  the  complete  life  cycle  of  manufactured 
products.  It  addresses  only  the  specification  of  products  and  not  the  manufacturing  process 
relationships.  The  DOD/CALS  IGES  standard  is  preferred  for  engineering  drawings,  electronics, 
and  numerical  control.  The  standard  is  optional  for  technical  manual  illustrations.  Version  5.0  of 
the  N1STIR  4412  does  not  contain  B-rep  solids.  However,  B-Rep  solids  are  contained  in  Version 
5.2. 


3.5.5.1.4  Portability  caveats.  STEP  is  an  international  standard  that  has  been  a  core  set  of 
Application  Protocols  that  have  been  implemented.  However,  interoperability  between  these  Aps 
cannot  alway  be  assured.  The  emerging  standard  is  still  unstable  and  liable  to  be  revised  at  any 
time,  thereby  creating  incompatibilities  that  limit  portability  and  interoperability. 

3.5.5.1.5  Related  standards.  The  following  standards  are  related  to  product  data  exchange  or 
product  data  exchange  standards: 

a.  ISO  7942:  Graphical  Kernel  System  (GKS) 

b.  ISO  9592:  Programmer's  Hierarchical  Interactive  Graphics  System  (PHIGS) 

c.  STEP  is  related  to  IGES,  but  was  extended  to  cover  the  full  life  cycle  of  products 
from  requirements  and  design  through  production  and  installation. 

d.  MIL-HDBK-1300A,  NITFS. 

e.  MIL-STD-2500A,  NITF,  Version  2.0  for  the  NITFS. 

f.  EIAs  Special  Report  CALS:  Harmonizing  CALS  Product  Data  Description 
Standards 
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3.5.5. 1.6  Recommendations.  ANSI/US  PRO/IPO  100-1996  (Formerly  IGES)  is  Year  2000 
compliant  and  is  recommended  except  for  cases  where  STEP  provides  additional  capabilities  that 
are  lacking  in  IGES  and  are  critical  to  the  accomplishment  of  the  system.  STEP  includes  IGES's 
functionality,  but  is  more  comprehensive.  Moreover,  CALS  specifies  five  classes  of  IGES  files: 
Technical  Illustration  (I),  Electrical/Electronic  (II),  Engineering  (IE),  Numerical  Control 
Manufacturing  (IV),  and  3D  Piping  (V). 

IGES  products  are  implemented  widely  and  are  likely  to  be  proposed  by  vendors  whether  or  not  a 
procurement  specifies  it.  In  contrast,  STEP  products  must  be  specified  explicitly.  If  STEP  is 
specified  in  a  procurement,  then  it  should  conform  to  the  requirements  in  the  ISO  10303  STEP. 

The  DOD/CALS  IGES  standard  is  preferred  for  engineering  drawings,  electronics  drawings,  and 
numerical  control.  The  standard  is  optional  for  technical  manual  illustrations.  It  defines  subsets 
for  technical  illustrations,  engineering  drawings,  electrical/electronic  applications,  and  numerical 
control  manufacturing,  and  includes  an  application  protocol  for  three  dimensional  piping 
information. 

The  ISO  10303  STEP  standard  is  a  set  of  interrelated  standards  that  define  a  vocabulary  and 
syntax  for  the  exchange  of  product  data.  The  scope  of  ISO  10303  encompasses  all  aspects  of 
product  data  that  may  be  collected  and  exchanged  for  any  product  throughout  the  life  cycle.  In  its 
current  state,  ISO  10303  primarily  addresses  the  exchange  of  material  and  shape  data.  ISO  10303 
is  a  standard  designed  for  expansion.  As  such,  a  large  part  of  its  initial  content  lays  in  the 
conceptual  framework  from  which  any  topic  area  of  product  data  may  be  standardized  to 
exchange  data. 

Two  specific  applications  to  be  included  in  the  initial  version  of  STEP  concern  the  exchange  of  2- 
D  drafting  data  and  the  exchange  of  configuration  controlled  3-D  design  data. 
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3JS2  Business  data  interchange.  Business  data  interchange,  also  known  as  EDI,  refers  to  a 
family  of  national  and  international  standards  that  support  the  intercompany,  computer-to- 
computer  exchange  of  business  documents  in  standard  formats.  Examples  of  common  business 
documents  exchanged  using  EDI  are  invoices,  bills  of  lading,  purchase  orders,  technical  drawings, 
business  graphics,  compound  documents,  catalogs,  price  lists,  electronic  funds  transfer 
information,  and  promotional  announcements.  EDI  is  gaining  prominence  for  technical  data. 

3. 5.5. 2.1  Standards.  Table  3.5-29  presents  standards  for  business  data  interchange. 


TABLE  3.5-29  Business  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

NIST 

Electronic  Data  Interchange  (EDI)  (adopt!  families  of 
standard*  known  at  ANSI  Xl2and  EDIFACT) 

FIPS  PUB  161- 

1:1993 

Adopted 

(Approved) 

IPC 

ISO 

Trek  D*u  Element!  Dictionary  (TOED) 

7372:1986 

Informational 

(Approved) 

IPC 

ISO 

Electrode  Data  Interchange  for  Admidstration, 
Commerce,  &  Transport  (EDIFACT)  Application  Level 
Syntax  Rule* 

9735:1988 

Informational 

(Approved) 

NPC 

ANSI 

Electronic  Data  Interchange  (EDO-Many  Transaction  Sets 

X 12. 1*3, 5-10. 12- 
16, 20, 22-all  1989 

Informational 

(Approved) 

IPC 

itu-t 

X.435 (1991) 

Informational 

(Approved) 

IPC 

UN  Boon.  Comm. 
For  Europe 

United  Nations  Trade  Data  Interchange  Directory 
(UNTDID) 

IB 

Informational 

(Anmved) 

IPC 

ISO/IEC 

Reconciliation  of  IEEE  1 175  (CDIF)  and  STEP 

JTCI/SC21/W03 

Informational 

(TBD) 

IPC 

ISO/IEC 

EDEPACT+  (Merged  ANSI  X.12  &  CC1TT  X.435) 

9735  (future) 

Informational 

(Formative) 

IPC 

ISO/IEC 

Proposed  EDIFACT/FTAM  Document  Type 

JTC!/SC21.Wa5, 

N6224 

Informational 

(Draft) 

3.5.S.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  EDI  II:  EDI  functionality  that  surrounds  applications,  rather  than  having  to  be 
buried  within  the  applications. 

b  Imaging  Technologies  that  electronically  digitize  an  image  of  a  paper  document, 
such  as  an  invoice  or  a  purchase  order,  along  with  subsequent  retrieval  and 
document  processing  capabilities. 

3.5.5.2.J  Standards  deficiencies.  EDI  for  Administration,  Commerce,  and  Transport 
(EDIFACT)  specifies  only  an  EDI  message  architecture.  X12  specifies  transaction  sets  for 
several  business  applications,  but  does  not  cover  all  transaction  sets  needed  by  government 
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agencies.  Applicable  transaction  sets  need  to  be  developed.  EDIFACT  does  not  currently 
support  the  transmission  of  binary  files  or  technical  data.  Adoption  of  a  solution  is  imminent  and 
should  be  included  in  version  4  of  ISO  9735  in  the  spring  of  1995. 

ISO  9735  EDI  does  not  provide  security.  The  1984  version  of  X.400  is  not  adequate  for  EDI. 
The  1988  X.400/X.435  version  is  needed  to  handle  EDI  messages.  P.edi  works  only  with  the 
1988  version  of  X.400.  X12  supports  the  transmission  of  technical  data  through  transmission  set 
841. 

Up  to  85  percent  of  EDI  documents  still  have  to  be  rekeyed  several  times  by  senders  and 
recipients,  largely  defeating  the  purpose  of  EDI,  unless  users  substantially  restructure  their 
business  processes. 

3.5.5.2.4  Portability  caveats.  The  ISO  EDIFACT  standard  is  not  aligned  with  ANSI  X12, 
although  work  is  underway  to  align  the  two  standards.  An  estimate  of  when  this  alignment  is 
likely  to  take  place  :s  difficult  to  make.  EDIFACT  and  X12  differ  in  syntax  control  segments,  data 
segments,  and  data  elements. 

3.5.5.2.5  Related  standards.  The  following  standards  are  related  to  business  data  interchange  or 
business  data  interchange  standards: 

a.  ISO  646: 1991 :  7-Bit  Coded  Character  Set  for  Information  Interchange 

b.  ISO  8571:  FTAM 

c.  ISO  8632: 1987:  CGM 

d.  ISO  8824:  ASN.l 

e.  ISO  8825:  BER 

f.  ISO  8879: 1988:  SDIF 

g.  ISO  9069: 1 988:  SGML  Support  Facilities  for  SDIF 

h.  ISO  Draft  Proposed  Standard  (DP)  10303:  STEP 

i.  Various  ISO  standards  for  coded  character  sets  and  graphic  characters 

j.  ITU-T  X.400:  MHS 

k.  ITU-T  X.435:  Messaging  protocols  used  to  send  EDI  messages  through  an  X.400 
network 

l.  ISO/IEC  DIS  13208:  Electronic  data  interchange  messaging  system 
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m.  ISO/IEC  DIS  13209:  Electronic  data  interchange  messaging  service 

n.  ANSI/ASME  Y14.26M-1989:  IGES  v.4.0 

3.5. 5.2, 6  Recommendations.  FIPS  PUB  161  recommends  the  use  of  X12  standards  for  domestic 
applications,  and  X12  or  EDIFACT  for  international  interchanges.  Both  families  of  standards 
may  be  employed  to  meet  organizational  needs. 

DOD  components  that  implemented  EDI  systems  after  September  30, 1991,  are  required  to 
conform  to  FIPS  PUB  161.  DOD  components  that  implemented  EDI  systems  before  September 
30, 1991,  using  industry-specific  standards,  have  until  September  30, 1996,  to  convert  to  the 
standards  specified  in  FIPS  PUB  161. 

Migration  to  X.435  is  recommended  as  soon  as  possible,  especially  for  international  operations 
because  EDI  over  X.400  is  already  in  production  in  Europe. 

When  specifying  EDI  services,  include  compliance  CCITT  Recommendation  X.435  and  applicable 
portions  of  NIST  Special  Publication  500-183  (Stable  Implementation  Agreements). 

To  maximize  portability  and  interoperability,  procurements  must  specify  the  ITU-T  1988  X.4O0 
MHS  Recommendations  or  later  and  avoid  the  use  of  products  that  conform  to  the  1984 
Recommendation.  For  partially  existing  systems,  FIPS  PUB  161  encourages  the  "interim"  use  of 
message  handling  system  implementations  built  in  conformance  with  the  ITU-T  1984  X.400 
Recommendation. 
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3.5.5  J  Computer  aided  software  engineering  (CASE)  tool  data  interchange.  These 
standards  provide  formats  for  the  exchange  of  data  between  CASE  tools. 

3.5.5.3.1  Standards.  Table  3.S-30  presents  standards  for  CASE  tool  data  interchange. 


TABLE  3 .5-30  Computer  aided  software  engineering  (CASE)  tool  data  interchange 
_ standards _ 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

PFPF 

Standard  Reference  Model  for  Computing  Sy  Hem 
Engineering  Tool  Inter  connections 

1175:1992 

Informational 

(Approved) 

NPC 

Trial-Use  Standard  Reference  Model  for  Computing 
System  Tool  Interconnections 

TR  1175:1992 

Informational 
(Approved  (Trial- 
Use)) 

NPC 

mrr 

Recommended  Practice  for  the  Evaluation  and  Selection  of 
CASE  Tools 

1209:1993 

Informational 

(Approved) 

NPC 

E1A 

CASE  Data  Interchange  Format  (CD  IF),  Frame  work  for 
Modeling  and  Extensibility;  Transfer  Format  Definition; 
CASE  Interchange  Meta-model 

IS-8I.IS-82.  IS-83 
of  July,  '  ‘91 

IPC 

ISO 

Portable  Common  Tool  Environment  (PCTE)  -  Part  2:  C 
Programming  Language  Binding 

13719-2:1995 

Informational 

(Approved) 

IPC 

ISO 

Portable  Common  Tool  Environment  (PCTE)  -  Part  3:  Ada 
Programming  Language  Binding 

13719-3:1995 

Informational 

(Approved) 

NPC/IPC 

ANSI/TSO 

Information  Resources  Dictionary  System  2  (1RDS2) 
(Repository  standard  revision  will  include  an  interface  with 
CASH  tools) 

JTC 1/2 1.06. 04,5; 

ANSI  X3H4 
Project  0754-D  (or 

_ 2D _ 

Informational 

(Formative) 

3.S.S3.2  Alternative  specifications.  No  consortia  or  de  facto  specifications  are  available. 

3.5.5.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown.  This  is  a 
fledgling  standardization  area,  but  it  is  advancing  rapidly. 

3.5.5. 3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.5.5.3.5  Related  standards.  The  following  standards  are  related  to  case  tool  data  exchange  or 
exchange  standards: 

a.  ECMA  149  PCTE  (Portable  Common  Tools  Environment) 

b.  ECMA,  European  regional  standards  organizations,  and  the  European  Defense 
Community:  PCTE+ 

c.  DOD-STD- 1 838A:  Common  Ada  Programming  Support  Environment  (APSE) 
Interface  Set  (CAIS-A) 
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d.  ECMA  TR  55  CASE  Reference  Model 

e.  ISO  Draft  International  Standardized  Profile  (DISP)  10609-23: International 
Standardized  Profile  TB,  TC,  TD  and  TE  -  Connection-Mods  Transport  Service 
over  Connection-Mode  Network  Service  -  Part  23:  Subnetwork-Type  Dependent 
Requirements  for  Network  Layer  and  Data  Link  Layer  for  Data  1'ransfer 
Concerning  a  Packet  Switched  Mode  Integrate 

f.  ISO  DISP  10609-24:  International  Standardized  Profile  TB,  TC,  TD  and  TE  - 
Connection- Mode  Transport  Service  over  Connection-Mode  Network  Service  - 
Part  24:  Subnetwork-Type  Dependent  Requirements  for  Network  Layer  and  Data 
Link  Layer  for  Data  Transfer  Concerning  a  Packet  Switched  Mode  Integrate 

g.  ISO  DISP  10609-26:  International  Standardized  Profile  TB,  TC,  TD  and  TE  - 
Connection-Mode  Transport  Service  over  Connection-Mode  Network  Service  - 
Part  26:  Subnetwork-!  ype  Dependent  Requirements  for  Network  Layer  for  Call 
Control  Procedures  Concerning  the  Outgoing  Call  of  a  Packet  Switched  Mode 

h.  ISO  DISP  10609-27:  International  Standardized  Profile  TB,  TC,  TD  and  TE  - 
Connection-Mode  Transport  Service  over  Connection-Mode  Network  Service  - 
Part  27:  Subnetwork-Type  Dependent  Requirements  for  Network  Layer  for  Call 
Control  Procedures  Concerning  the  Incoming  Call  of  a  Packet  Switched  Mode 

3  J.5  J.6  Recommendations.  It  is  recommended  that,  for  those  procurements  requiring  CASE 
tools  and  exchange  of  the  associated  data,  systems  migrate  to  IEEE  1 175,  CDIF,  Product  Data 
Exchange  Specification  (PDES)  or  the  STEP  for  CASE  tool  data  exchange. 
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3.5  .5.4  Circuit  design  data  interchange.  Circuit  data  interchange  standards  provide  a  format 
for  the  interchange  of  hardware  circuit  design  data. 

3.5.5. 4.1  Standards.  Table  3.5-31  presents  standards  for  circuit  design  data  interchange. 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

VHSIC  Hardware  Description  Language  (VHDL)  (adopts 
ANSI/IEEE  1076-1987) 

FIPS  PUB 
172:1992 

Adopted 

(Approved) 

NPC 

TFFF 

Standard  VHSIC  Hardware  Description  Language 
(VHDL)  Ref  Manual  Interpretations 

I076/INT-91 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Standard  VHSIC  Hardware  Deacription  Language 
(VHDL)  Reference  Manual 

1076:1987 

(R1993) 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

1164:1993 

Informational 

(Approved) 

:/pc 

ANSI/EIA 

Commercial  Component  Model  Specification 

5670000:1991 

Informational 

(Approved) 

NPC 

BA 

Introduction  to  Electronic  Design  Interchange  Pormat 
(EDIF),  Monograph  Series  Volume  1 

EDIF-1  of  Sept. 
1988 

Informational 

(Approved) 

NPC 

EIA 

Electronic  Design  Interchange  Format  (EDIF)  Connectivity 

Monograph  Series  Volume  2 

EDIF-2  of  June, 
1989 

Informational 

(Approved) 

NPC 

ANSI/KIA 

Electronic  Design  In  (etc  hinge  Foimat  (EDIF),  Version 
2n0n0n 

548:1988 

Informational 
(Approved  (May 
be  superseded)) 

NPC 

EIA 

Application  Guide  Using  Electronic  Data  Interchange 
Format  (EDIF),  V<*'  ‘  TnOnOn  for  Schematic  Transfer 

EDIF/AG- 1  of  July 
1989 

Informational 
(Approved  (May 
be  superserf:  4)) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  ICES  Application  SubaeU  tni  ICES  Application 
Protocols 

MIL-PRF-28000 

Informational 

(Approved) 

CPC 

CAD  Framework 
Initiative 

Procedure  Interface  (PI)  (for  circuit  connectivity  data) 

PI 

Informational 

(Approved) 

CPN-C 

Open  Verilog 
Inti. 

Verilog  HDL 

Informational 

(Approved) 

CPN-C 

Vendors 

Graphic  Design  System  II  (GDSH):  CAD  Exchange 
Format 

GDSII 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  (GES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-D-28000AG) 
of  12/14/92 

Informational 

(Superseded) 

CPC 

CAD  Framework 
Initiative 

CAD  Design  Tool  Interchange  Formal  (for  circuit  design) 
(Planned  to  be  submitted  to  ANSI) 

None  assigned  yet 

Informational 

(Formative) 

NPC 

IEEE 

Design  Management 

PI077 

Informational 

(Canceled) 

NPC 

IEEE 

Information  Model  for  Design  Language 

P1078 

Informational 

(Canceled) 

NPC 

IEEE 

Interface  for  IEEE  VHSIC  Hardware  Description 
Language  (IEEE  Standard  1076-1987)  to  CAD/CAM 
Tools 

PI  163 

Informational 

(Canceled) 

NPC 

IEEE 

Recommended  Practice  for  the  Interrelationships  between 
IEEE  1076  and  EIA  Standard  RS-44  EDIF 

PI  165 

Informational 

(Canceled) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

WPF. 

Standard  Delay  RIe  Format  (SDF) 

wmrrxm 

Informational 

(Drift) 

3S.S.4.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Cadence  Design  Systems'  Standard  Delay  File  format  (SDF),  developed  for  the 
Verilog  Hardware  Design  Language  (HDL),  which  has  been  introduced  as  the 
strawman  candidate  for  the  Institute  of  Electrical  and  Electronics  Engineers 
(IEEE)  standard  delay  file  format 

b.  Institute  for  Interconnecting  and  Packing  Electronic  Circuits  (1PC):  EPC-D-350, 
IPC-D-356. 

3.S.5.4J  Standards  deficiencies.  VHSIC  Hardware  Description  Language  (VHDL)  lacks  analog 
design  capabilities,  high-level  predefines  'ypes  (e.g.,  queues),  and  explicit  notations  for  finite  state 
machines.  VHDL  lacks  interfaces  with  other  design  and  programming  languages,  such  as  the 
Verilog  HDL  and  C.  This  issue  is  addressed  in  the  1992  revision  of  the  standard.  VHDL  does  not 
support  hierarchical  path  names.  This  issue  is  addressed  in  the  1992  revision  of  the  standard. 

No  formal  standard  or  industry-accepted  standard  practice  exists  for  representing  timing  data 
(e.g.,  delay  values)  in  VHDL  models  and  libraries.  For  VHDL  to  work  effectively  with  ASIC 
models,  a  neutral  format  for  technology-specific  data  is  needed  so  that  data,  such  as  delay 
information,  can  be  transmitted  independent  of  the  simulator.  The  IEEE  has  formed  a  working 
group  to  develop  a  methodology  for  accomplishing  this  goal. 

3.5.5.4.4  Portability  caveats.  Specialized  synthesis  tools  based  on  VHDL  are  emerging,  each 
requiring  a  different  variation  of  the  input  VHDL  language.  Each  tool  has  its  own  idiosyncrasies 
and  limitations,  some  of  which  stem  from  these  variations. 

Although  tools  based  on  the  Electronic  Data  Interchange  Format  (EDIF)  are  offered  by  many 
vendors  as  a  way  to  import  or  export  design  data,  the  EDIF  standard  is  being  supplanted  by  the 
Electronic  Industries  Association's  (ELA)  CASE  Data  Interchange  Format  (CDIF),  which  is  not 
totally  compatible  with  the  original  EDIF  specifications. 

Tools  based  on  VHDL  (the  formal  standard)  and  tools  based  on  Verilog  HDL  (the  widespread  de 
facto  standard)  do  not  interoperate.  The  use  of  VHDL  and  Verilog  will  require  users  to  maintain 
incompatible  tools  for  two  standards. 

3.5.5.4.5  Related  standards.  The  MIT  X  Consortium's  X  Window  System  is  related  to  hardware 
data  exchange. 
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3 .5 .5.4.6  Recommendations.  National  Institute  of  Standards  and  Technology  (NIST)  FIPS  172, 
VHDL,  is  recommended.  Disregard  claims  about  the  level  of  integration  among  tools.  Focus 
instead  on  using  VHDL  to  generate  a  design  at  the  highest  level  to  gain  the  benefits  of  top-down 
design.  Probably,  you  will  have  to  modify  some  code  for  each  tool. 

In  any  procurement  specifying  EDIF,  require  an  upgrade  path  from  EDIF  to  CDIF.  In  any 
procurement  specifying  the  VHDL,  specify  the  full  VHDL  (e.g„  a  full  VHDL  simulator)  rather 
than  any  subset  or  superset.  This  is  the  only  way  to  be  certain  that  the  VHDL  will  synthesize 
correctly. 

Vendors  delivering  VHDL  most  likely  will  deliver  the  1987  version  of  the  standard.  This  version 
lacks  several  important  capabilities  that  are  addressed  in  the  standard's  revision.  Therefore,  in  any 
procurement  specifying  VHDL,  require  vendors  to  explain  their  upgrade  paths  to  the  revised 
VHDL  standard. 

VHDL  synthesis  can  produce  a  high  productivity  level,  only  if  the  designers  know  how  to  drive  it 
and  how  to  write  out  VHDL  files  to  get  that  productivity.  Since  VHDL  is  relatively  new,  in  any 
procurement  specifying  VHDL,  it  is  advisable  to  require  training  from  the  vendor. 
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3J5.5.5  Military  logistics  and  document  support.  These  are  standards  for  creating 
documentation  of  military  systems  in  support  of  life  cycle  logistics  support 

3.55.5.1  Standards.  Table  3.3-32  presents  standards  for  military  logistics  and  document  support 


TABLE  35-32  Military  logistics  and  document  su 

poor*  standards 

Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

JH2 

GPC 

DOD 

Logirtic  Support  Analysis  (LSA)  Record 

MIL-STEM  388-2B 

Adopted 

(Approved) 

GPC 

DOD 

Automated  Interchange  of  Technical  Information  (Life 
cycle  logistic  support  of  weapon  systems) 

MIL-STD-1840B 
of  11/3/1992 

Adopted 

(Approved) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

GPC 

DOD 

Manuals,  Technical:  General  Style  and  Format 
Requirements 

M2L-M-387MC<3) 
of  12/9/1992 

Informational 

(Approved) 

GPC 

DOD 

Manuals,  Interactive  Electronic  Technical:  Genera) 
Content,  Style,  Format  and  User  Interaction  Requirements 

MIL- M- 87268  of 

1 1/20/1992 

Informational 

(Approved) 

GPC 

DOD 

Database  Revisable: Interactive  Electronic  Technical 
Manuals  for  the  Support  of 

MIL-D-87269  of 

1 1/20/1992 

Informational 

(Approved) 

GPC 

DOD 

Quality  Assurance  Program  Interactive  Electronic 
Technical  Manuals  (IETM)  and  Associated  Technical 
Information.  Requirements  for 

MfL-Q-87270of 

11/20/1992 

Informational 

(Approved) 

GPC 

DOD 

Defense  System  Software  Development 

DOD-STD-2167A 

Informational 

(Supeneded) 

GPC 

DOD 

DOD  Automated  Information  Systems  (AIS) 
Documentation  Standards 

DOD-STD-7935A 

Informational 

(Supeneded) 

GPC 

DOD 

DOD  Requirements  for  a  Logistic  Support  Analysis  Record 
(LSAR) 

MIL-STD- 1 388-2B 
of  3/28/1991 

Informational 

(Canceled) 

3.5.5.5.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Association  European  des  Constructeurs  de  Material  Aerospatial  (AECMA) 
1000D:  Specification  for  Production  of  Technical  Publications,  Utilizing  a 
Common  Source  Data  Base. 

b.  AECMA  2000M:  Specification  for  Material  Management,  and  Integrated  Data 
Processing  for  Military  Equipment. 

3.5.5.5.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.5.5.4  Portability  caveats.  Europe  has  its  own  versions  of  military  logistics  support  document 
interchange,  and  has  stated  that  it  will  adapt  the  CALS  versions  of  the  logistics  support  standards 
(MIL-STD-1388),  rather  than  adopt  them  without  change.  Although  Europe  will  seek 
compatibility,  its  failure  to  seek  compliance  can  lead  to  incompatible  areas.  North  Atlantic  Treaty 
Organization  (NATO)  is  looking  into  harmonizing  DOD  and  AECMA  logistics  standards. 
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If  hard  copies  of  documents  are  required,  it  should  be  noted  that  the  ISO  A4  paper  size  commonly 
used  ir.  Europe  for  international  communication  on  text  and  facsimile  equipment  is  longer  and 
narrower  than  that  used  in  the  United  States,  and  does  not  necessarily  work  with  standard  office 
equipment 

MIL-STDs  and  DOD-STDs  2167 A,  7935A,  and  1703  have  been  revised  and  consolidated  (aka 
MIL-STD-498,  Software  Development  and  Documentation).  In  light  of  DOD's  new  policy  on 
MIL-STDs,  the  project  has  been  moved  into  the  IEEE  standardization  process. 

35.5.5.5  Related  standards.  The  following  standards  are  related  to  military  logistics  and 
document  support  or  support  standards: 

a.  ISO  8571:  FTAM 

b.  ISO  8649:  Association  Control  Service  Element  (ACSE) 

c.  ISO  9066:  Reliable  Transfer  Service  Element  (RTSE) 

d.  ISO  9072:  ROSE 

35.5.5.6  Recommendations.  The  adopted  standards  are  recommended. 
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3 .5.5.6  Geospatial  data  interchange.  (This  BSA  appeals  in  part  5,  Data  Interchange,  and  part 
6,  Graphics.)  These  standards  provide  formats  and  facilities  for  machine-readable  graphics-based 
mapping,  charting,  and  geodesy  data. 

3. 5.5.6. 1  Standards.  Table  3.5-33  presents  standards  for  geospatial  data  interchange. 


TABLE  3.5-33  Geospatial  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD  (NIMA) 

World  Geodetic  System  (WGS  84) 

MIL- STD- 2401  of 
21  March  1994 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Raster  Product  Format  (RPF) 

MIL-STD- 

2411:1994 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Interface  Standard  for  Vector  Product  Format  (VPF) 

MIL-STD-2407 

Mandated 

(Approved) 

IPC 

NATO 

STANAG  7074 

Informational 

(Approved) 

GPC 

NIST 

Spatial  Data  Tranifer  Standard  (SDTS) 

FIPS  PUB  173- 

1:1994 

Informational 

(Approved) 

IPC 

NATO 

Digital  Terrain  Elevation  Data,  (DTED) 

STANAG  3809 

Informational 

(Approved) 

GPC 

NIST 

Representation  of  Geographic  Point  Locations  for 
Information  Interchange  (adopts  ANSI  X3.6 1*1986) 

FIPS  PUB  70- 
1:1986 

Informational 

(Approved) 

GPC 

NIST 

Codes  for  Identification  of  Hydrologic  Units  in  the  United 
States  and  the  Caribbean  Outlying  Areas  (adopts  USGS 
Circular  878- A  and  ANSI  X3. 145- 1986) 

FIPS  PUB 
103:1983 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

NIMA  GGI&S  List  of  Products  and  Services 

NIMAL  805-1  A, 
Jan  1997 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Arc  Digitized  Raster  Graphics  Worldwide  Map  Images  on 
CD-ROM,  1:5 ,000  through  1:2,000,000 

M1L-A-89007  of 
2/22/1990 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

DTED  (Machine  readable  lemin/elevation  data  for  the 
U.S.,  the  former  USSR,  Europe,  Central  Asia,  Mideast, 
Parts  of  Southern  Asia,  Northern  Canada,  3- Arc-Sec) 

MIL-D-89000  of 
2/26/90  MIL-D- 
89001  of  2/26/90 
MIL-D-89020  of 
5/28/93 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

MIL-D-89009  of 
4/13/92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Digital  Cities  DaU  Base  (DCDB) 

M1L-D-890)  1  of 
7/2/90 

Informational 

(Approved) 

OPC 

DOD  (NIMA) 

Firefinder  Elevation  Data  (FED) 

MIL-D-89018  of 
10/1/92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Digital  Landmass  Blanking  (DLMB) 

MIL-D-89021  of 
6/1 5/9 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Interim  Terrain  Data/PI inning  Interim  Terrain  Data 
(1TD/PITD) 

MIL-i-89014  of 
11/30/90 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Video  Disc  for  Mapping,  Charting  and  Geodesy 
(Worldwide  Map  Images  on  12  inch  Video  Disk,  1:50,000 
through  1:1,000,000) 

MIL-V-89300(  l)  of 
11/30/92 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecyde) 

OPC 

DOD(NlMA) 

World  Vector  Shoreline  (showing  Worldwide  Coutiine* 
and  International  Boundaries,  1:250,000  acale) 

MIL-W-890I2<2) 
of  11/3(V92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

World  Magnetic  Model  (WMM) 

MIL-W-895O0  of 
6/18/93 

Informational 

(Approved) 

OPC 

DARPA 

SIMNET  Geographic  Data  Model  and  Database 
Interchange  Specification 

BBN  DARPA 
Report  7 1C*  July 
1989 

Informational 

(Approved) 

GPC 

NGDC 

Worldwide  Coverage  for  5  Mini  Grid  map*: 
Bathymetri  elevation  Data 

BT0PO5 

Informational 

(Approved) 

GPC 

USGS 

LANDS  AT:  Worldwide  Coverage  for  1 : 1 ,000.000  Scale 
Map*:  Peature/Terrain  Data 

LANDSAT 

Informational 

(Approved) 

irc 

NATO 

Scope  and  Presentation  of  Military  Geographic  Information 
and  Documentation 

STANAG  2251 

Informational 

(Approved) 

IPC 

NATO 

Road*  and  Road  Structure! 

STANAG  2253 

Informational 

(Approved) 

IPC 

NATO 

MOD- Porta 

STANAG  2255 

Informational 

(Approved) 

IPC 

NATO 

Indexer  to  aerie*  of  Land  Map*  and  Aeronautical  Chart* 
and  Indexes  to  Military  Geographic  Information  and 
Documentation  CMG1D) 

STANAG  3672 

Informational 

(Approved) 

IPC 

NATO 

Preferred  Magnetic  Tape  Standard*  for  the  Exchange  of 
Digital  Geographic  Information 

STANAG  3985 

Informational 

(Approved) 

IPC 

NATO 

Digital  Data  File  Tranrmittal  Form  for  Geographic 
Information 

STANAG  3986 

Informational 

(Approved) 

GPC 

USGS 

Specification  for  Representation  of  Geographic  Point 
Location*  for  Information  Interchange  (adopt*  ANSI 
X3.6M986) 

USOS  Circular 
878-B  of  1983 

Informational 

(Approved) 

GPC 

USGS 

Digital  Elevation  Model* 

USGS  Circular 
895-B  of  1983 

Informational 

(Approved) 

GPC 

USOS 

Digital  Line  Graph*  from  1 :24,000  Scale  Map* 

USGS  Circular 
895-C  of  1983 

Info*  yational 
(Ai ,  roved) 

GPC 

USGS 

Digital  Line  Graphs  from  1:2,000,000  Scale  Map* 

USGS  Circular 
895-Dof  1983 

Informational 

(Approved) 

GPC 

USGS 

Land  Use  and  Land  Cover  Digital  Data 

USGS  Circular 
895-E  of  1983 

Informational 

(Approved) 

GPC 

USGS 

Geographic  Name*  Information  System 

USGS  Circular 
895-Fof  1983 

Informational 

(Approved) 

GPC 

CIA 

World  Data  Bank  11:  Worldwide  Coverage  for  1:2,000.000 
Scale  Map*  (Line*  of  Communication,  Coast  line*. 
Waterways,  Inlemalionai/Political  Boundaries) 

World  Data  Bank  II 

Informational 

(Approved) 

GPC 

DOD  (USAF) 

Arc  Digital  Ruler  Imagery  (ADRI)  Format 

MiL-STD-2406 

Informational 

(Final) 

GPC 

DOD  (NIMA) 

Standard  Linear  Format  (SLF)  Digital  Cartographic 
Feature 

MIL-HDBK-854 

Informational 

(Final) 

GPC 

IX)D  (AFMC) 

Registered  Data  Value*  for  Ruter/Gridded  Product  Formal 

M1L-HDBK-856 

Informational 

(Final) 

GPC’ 

DOD  (NIMA) 

Text  Product  Form  (TPF) 

M1L-STD-2400 

Informational 

(Final) 

OPC 

l*  >1)  (NIMA) 

Mapping  Charting  and  Geodesy  Symbology  Graphics 

MIL- STD- 600002 

Informational 

(Draft) 

April  7,  1997 


3.5-64 


Version  3.1 


Information  Technology  Standards  Guidance 


Data  Interchange  Services 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

Header  Record  Foimai  for  Exchange  of  Digital  Geographic 
Information 

STANAG  3984 

Informational 

[PC 

NATO 

Digital  Geographic  Information  Data  Seta  S erica 
Ntanbenag 

STANAG  7070 

Informational 

(Draft) 

GPC 

DOD  (NIMA) 

MIL- D- 8 9005 

Informational 

(Draft) 

OPC 

DOD  (NIMA) 

Tactical  Terrain  Data:  Digital  Database  for  1 :50,000  Scale 

Map* 

TBD-Tacticai 

Terrain  Data: 
Digital  Database 

for  1:50,000  Scale 

Map* 

Informational 

(Formative) 

3 .5. 5.6.2  Alternative  specifications.  Many  existing  proprietary  map  graphics  applications  vary  in 
complexity  to  meet  users'  needs.  These  applications  serve  as  the  cornerstone  of  the  mapping, 
charting,  and  geodesy  areas  requiring  further  investigation  for  standardization  consideration. 

3.5.S.6  .3  Standards  deficiencies.  Many  of  the  standards  listed  in  the  table  accompanying  this 
section  are  old.  They  do  not  accommodate  new  sophisticated  computerized  techniques,  and 
probably  will  be  replaced  in  the  next  several  years.  The  standards  available  pertain  almost 
exclusively  to  the  data  rather  than  the  functionality  of  an  application. 

3.5.S.6.4  Portability  caveats.  Portability  will  be  reduced  if  a  Geographic  Information  System 
(G1S)  does  not  allow  users  to  associate  their  cartographic  data  independently  with  relational 
database  management  systems  based  on  SQL. 

The  use  of  different  file  formats  by  a  GIS  reduces  portability.  However,  in  the  production  world 
several  file  formats  specified  by  v  'ors  are  used  so  widely  that  they  are  considered  neutral  file 
formats  (e.g..  Intergraph's  Standard  Interchange  Format  (SIF),  Autodesk's  Drawing  Exchange 
Format  (DXF),  and  Map  Overlay  Statistical  System  (MOSS)). 

Traditionally,  standards  governing  exchanges  among  field  systems  have  been  the  responsibility  of 
the  military  system  development  organization.  This  leads  to  substantial  interoperability  problems, 
particularly  international.  To  maximize  interoperability.  Digital  Geographic  Information 
Exchange  Standard  (DIGEST)  and  other  map  producing  data  should  be  exchanged  between  map- 
producing  agencies,  such  as  the  National  Imagery  and  Mapping  Agency  (NIMA)  and  not  between 
operational  units,  and  the  systems  development  organizations  should  use  the  standards  set  by  such 
agencies  as  the  NIMA. 

Portability  difficulties  may  exist  between  the  Vector  Product  Format  (VPF)  and  the  Spatial 
Transfer  Specification  (SDTS). 

Because  too  many  standards  exist,  the  situation  is  equivalent  to  having  no  standards. 
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3JJ.6J  Related  standards.  The  following  standards  are  related  to  map  graphics  exchange  or 
exchange  standards: 

a.  ISO  646: 7-bit  Coded  Character  Set  for  Information  Interchange 

b.  ISO  1001:  File  Structure  and  Labeling  of  Magnetic  Tapes  for  Information 
Interchange 

c.  ISO  2375:  Non-Latin  Alphabets 

d.  ISO  6937:  Supplementary  Characters  (for  accents  to  the  text) 

e.  ISO  8211:1985  Specification  for  a  Data  Descriptive  File  for  Information  Exchange 

f.  ISO  8824/8825:  ASN.l 

g.  ISO  9292:  Picture  Coding 

h.  ISO  9660: 1988  Volume  and  File  Structure  of  CD  ROM  for  Information  Exchange 

i.  ANSI/ASME  Y14.26M-1989:  IGES  (Neutral  file  format) 

j.  Intergraph  Corporation,  Huntsville,  AL:  SIF 

k.  Autodesk,  lnc„  Sausalito,  CA:  DXF 

l.  Autometric,  Inc.,  Lakewood,  CO:  MOSS 

m.  The  various  data  compression  standards  listed  earlier  in  the  section  on  data 
compression 

3SS.6.6  Recommendations.  GIS  specifications  in  a  procurement  should  require  SQL 
compatibility  so  that  cartographic  data  can  be  associated  independently  with  relational  database 
management  systems  based  on  SQL.  In  each  case,  consideration  of  the  scale  of  data  and 
geographic  region  needed  will  be  a  primary  determinant  in  selection.  The  standards  in  the  table 
above  labeled  mandated  are  recommended.  The  VPF  is  preferred. 

If  a  packaged  GIS  is  to  be  purchased,  if  possible,  it  should  be  standardized  around  a  single  GIS 
file  format.  If  a  GIS  is  to  be  used  on  workstations  and  PCs,  this  may  not  be  possible.  Then  the 
agency's  focus  will  have  to  be  on  the  use  of  interoperability  protocols  and  designing  applications 
for  portability.  GIS  specifications  should  require  SQL  compatibility  so  that  cartographic  data  can 
be  associated  independendy  with  relational  database  management  systems  based  on  SQL. 


April  7,  1997 


3.5-66 


Version  3. 1 


3 .5.5.7  Symbology  graphics.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  6, 
Graphics.)  These  are  standards  for  the  symbology  to  be  used  in  geospatial  applications  such  as 
hardcopy  mapping  products  and  computer-generated  displays.  DoD  standards  provide  definitions 
for  the  representation  of  military  and  intelligence  information. 

3.5 .5.7.1  Standards.  Table  3.3-34  presents  standards  for  symbology  graphics. 


TABLE  3.S-34  Symbology  graphics  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

in 

OPC 

DOD  (l)S  Army) 

Human  Factor*  Engineering  Deaign  Criteria  for  Helicopter 
Cockpit  Electro-Optical  Diiplay  Symbology 

MIL-STD-I295A 
of  6/26/1984 

Adopted 

(Approved) 

GPC 

DODftJSAF) 

Aircraft  Diiplay  Symbology 

MIL-STD-I787B 
of  6/93 

Adopted 

(Approved) 

OPC 

DOD  (NIMA) 

Mapping,  Charting  and  Geodesy  (MCAG)  Symbology  for 
Graphic  Products 

MIL-STD-2402  of 
2/95 

Adoptod 

(Approved) 

OPC 

DOD  (DISA) 

Common  Weighting  Symbology,  Version  I 

MIL-STD-2525 

Adopted 

(Approved) 

GPC 

WMO 

WMO  Document 
#49  of  1988 

Adopted 

(Approved) 

GPC 

DOD 

Military  Symbols 

Q-STAG  509  of 
3/5/1979 

Informational 

(Approved) 

NPC 

ANSI/SAB 

Human  Interface  Design  Methodology  for  Integrated 
Display  Symbology 

ARP  4 155  (1990) 

Informational 

(Approved) 

GPC 

DOD  (US  Army) 

Symboli  for  Army  Air  Defense  System  Displays 

MIL-STD-1477B 
of  2/1/1993 

Informational 

(Approved) 

GPC 

DOD  (DISA) 

Common  Warfighting  Symbology,  Version  2 

MIL-STD-2525A 

Informational 

(Approved) 

GPC 

DOD  (US  Amy) 

Army  Field  Manual  (FM):  Operational  Terns  and  Symbols 

ISI 

m  5C5R!E5mI 

Informational  U 
(Approved)  H 

NPC 

ANSI/ISA 

Instrumentation  Symboli  and  Identification 

S5. 1-1984  CHI 992) 

Informational  H 
(Approved)  8 

NPC 

ANSI/ISA 

Graphic  Symboli  for  Procesi  Diiplay* 

S5.5-1985 

Informational  I 
(Approved)  | 

IPC 

NATO 

NATO  Experimental  Tactic*  and  Amplifying  Tactical 
Instmction*  •  AXP-5(B)  (Navy/Air) 

STAN  AG  1125 

Informational  | 
(Approved)  I 

IPC 

NATO 

Military  Symbol*  for  Land  Based  Systems  (APP-6.  Ed  3) 

STANAG  2019(1) 
of  1 1/26/1990 

Informational 

(Approved) 

ipc 

NATO 

Electronically  and/or  Optically  Generated  Aircraft  Displays 
for  Fixed  Wing  Aircraft 

STANAG  3648  of 
6/29/1990 

Informational 

(Approved) 

IPC 

NATO 

Symbols  on  Land  Maps,  Aeronautical  Chans  and  Special 
Naval  Charts 

STANAG  3675 

Informational 

(Approved) 

IPC' 

NATO 

STANAG  3833 

Informational 

(Approved) 

GPC 

CJCS 

joint  Symbols  and  Graphics 

Joint  Pub  1-06 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD  (US  Army) 

Anny  Field  Manual  (FM):  Operation*]  Terms  and  Symbols 

FM  101-5-1 A 
SMIGS 

Informational 

(Drift) 

GPC 

DOD  (NIMA) 

Vector  Product  Format  Symbology 

MIL-PRF-89045 

Infoimstional 

(Drift) 

GPC 

DOD  (ASPO) 

Symbol  Automstion 

MIL-STD- Z5  26 

Informational 

(Draft) 

GPC' 

DIA 

Standard  Military  Graphics  Symbols  (SMIGS) 

DIAM6S-U 

Informational 

(Drift) 

IPC 

NATO 

Display  Symbology  and  Colors  for  NATO  Maritime  Units 

STANAG  4420 

Informational 

(Formative) 

3 .5.5. 7.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.5.5.7  .3  Standards  deficiencies.  Draft  MIL-STD-2525A  does  not  currently  contain  weather, 
geospatial  (mapping/charting),  cockpit  display,  and  engineering  design  symbology.  Therefore 
NIMA  M1L-STD-2402, 2412  should  be  used  for  geospatial  symbology  until  such  time  as  a 
decision  is  made  to  modify  MIL-STD-2525A  to  accomodate  these  symbols. 

3  J.5.7.4  Portability  caveats.  Portability  will  be  reduced  if  a  G1S  does  not  allow  users  to 
associate  their  cartographic  data  independently  with  relational  database  management  systems 
based  on  SQL.  Only  government  standards  are  available.  Most  commercial  products  will  not 
comply  with  these  standards. 

3.5.5.7.5  Related  standards.  The  following  standards  are  related  to  symbology  graphics  or 
symbology  graphics  standards: 

a.  ISO  6937:  Supplementary  Characters  (for  accents  to  the  text) 

b.  ISO  9292:  Picture  Coding 

c.  Autometric,  Inc.,  Lakewood,  CO:  MOSS 

d.  Map  graphics  standards. 

3.5.5.7.6  Recommendations.  The  adopted  symbology  standards  are  recommended,  as  applicable; 
MIL-STD  2525  is  the  recommended  standard  for  warrior  symbology. 
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3 .5.5.8  Continuous  Acquisition  and  Life-Cycle  Support.  Continuous  Acquisition  and  Life- 
Cycle  Support  (CALS)  standards  specify  the  digital  exchange  of  documents.  CALS  is  one  part  of 
a  broad  Electronic  Commerce  (EC)  initiative  within  the  DOD  that  has  the  potential  for 
converging  CALS  standards  and  enabling  technologies  within  the  Open  Systems  Environment 
(OSE).  CALS  has  begun  to  emerge  from  its  legacy  as  support  for  weapon  systems  technical 
documents.  Current  and  projected  CALS  standards  will  rationalize  their  native  standards  and 
emphasize  the  use  of  external  Open  Systems  standards  for  their  products,  permitting  format 
conversion  and  extensions  to  deal  with  complex  documents. 

3. 5.5. 8.1  Standards.  Table  3.5-35  presents  standards  for  continuous  acquisition  and  life-cycle 
support. 


TABLE  3.5-35  Continuous  Acquisition  and  Life-Cycle  Support  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Automated  Interchange  of  Technical  Information  (Life 
cycle  logistic  support  of  weapon  systems) 

MIL'STD-1840B 
of  11/3/1992 

Adopted 

(Approved) 

GPC 

DOD 

Contractor  Integrated  Technical  Information  Service 
(OTIS) 

MIL-STD-974 

Adopted 

(Approved) 

GPC 

DOD 

Department  of  Defense  Continuous  Acquisition  and  Life- 
Cycle  Support  (CALS)  Program  Implementation  Guide 

MIL-HDBK-59B 

Adopted 

(Approved) 

GPC 

DOD 

Manuals,  Interactive  Electronic  Technical:  General 
Content,  Style,  Format  and  User  Interaction  Requirements 

MIL-M-87268 

1 1/20/1992 

Adopted 

(Approved) 

GPC 

DOD 

Database  Revisable: Interactive  Electronic  Technical 
Manuals  for  the  Support  of 

MIL-D-87269  of 

1 1/20/1992 

Adopted 

(Approved) 

GPC 

DOD 

Qiality  Assurance  Program  Interactive  Electronic 
Technical  Manuals  (IETM)  and  Associated  Technical 
Information,  Requirements  for 

MIL-Q- 87270  of 

1 1/20/1992 

Adopted 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-PRF-28000 

Informational 

(Approved) 

GPC 

DOD 

Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  text  (based  on 
ISO  8879) 

MIL-PRF-28001 

Informational 

(Approved) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binaiy 
Format  (Group  4  Raster  Scanned  Images) 

MIL-PRF-28002 

Informational 

(Approved) 

CPC 

DOD 

MIL-PRF-28003 

Informational 

(Approved) 

GPC 

DOD 

Handbook  for  use  of  MIL-M-28001B 

MIL-HDBK-28001 

Informational 

(Formative) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-D-28000AG) 
of  12/14/92 

Informational 

(Superceded) 

GPC 

DOD 

Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  text  (based  on 
ISO  8879) 

MIL- M- 2800 IB  of 
6/26/1993 

Informational 

(Superceded 

(CALS)) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL-R-28002B  of 
12/14/1992 

Informational 

(Superceded 

(CALS)) 

GPC 

DOD 

wmmmmwmm 

MIL-D-28003AG) 
of  8/14/1992 

Informational 

(Superceded) 
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3S.5J&.2  Alternative  specifications.  The  AAP  TEI  has  designed  an  al  emative  nonproprietary 
architecture  with  SGML  encodings. 

3.5 .5.8.3  Standards  deficiencies.  Markup  consists  of  the  common  sets  of  document  formatting 
codes  used  in  classes  of  document  types.  Each  document  type  commonly  uses  a  particular 
publishing  style.  Technical  manuals  may  use  a  different  makeup  from  management  guideline 
documents  to  accommodate  the  audience,  contt, and  publishing  layout  styles.  Since  SGML 
does  not  deal  with  the  markup's  meaning,  it  does  not  specify  what  to  do  after  the  document  has 
been  processed  by  a  program  that  recognizes  SGML. 

SGML  does  not  use  ooject-oriented  methods  or  deal  with  hypermedia/time-based  document 
interchange.  Standards  in  both  areas  are  under  development. 

MIL-PRF-2800 1  uses  relatively  few  SGMI,  features  and,  therefore,  restricts  and  minimizes  the 
effectiveness  of  the  markup.  However,  the  standards  can  be  used  to  transfer  revisable  documents. 
However,  the  DOD/CALS  standard  mainly  is  used  for  weapon  system  technical  support 
doc  ments,  with  limited  application  to  business  office  environments. 

3 J.5.8.4  Portability  caveats.  The  DOD  CALS  have  limited  functionality  when  compared  with 
OQA/ODIF  and  other  standards  used  in  support  of  business  operations.  Users  should  treat 
complex  and/or  rompound  documents  with  care  to  ensure  upward  compatibility  with  ev  jiving 
standards. 

Eurof  ean  decisions  to  adapt  rather  than  full;  adopt  CALS  standards  may  lead  to  incompatibilities. 

3.5.5.8.5  Related  standards.  The  following  standards  are  related  to  CALS  standards. 

a.  ISO  8879:  SGML 

b.  ISO  8632:  CC.M 

c.  IGES  Version  4.0,  5.2 

d.  ISO  8879:1988:  SDIF 

e.  ISO  9069: 1988:  SGML  Support  Facilities  for  SDIF 

f.  MIL-STD  974:  Contractor  Integrated  Technical  Information  Service  (CITIS) 

g.  MIL-HDBK-59:  CALS  Yogrant  Implementation  Guide 

3.5. 5.8.6  Recommendations.  The  CAL  ,  standards  are  recommended  where  they  apply.  The 
DOD  SGML  standard  (MIL-PRF-2800 1)  is  based  on  ISO  8879.  In  the  meantime  jse  DOD 
SGML  ;n  coniunction  with  other  specifications  that  determine  the  markup's  meaning  (such  as  the 
EMPM  of  the  ODA  (ISO  8613).  Refer  to  the  document  exchange  BSA  for  further  SGML 
recommendations. 

IGES  is  recommended  when  multivendor  product  data  exchange  capabilities  are  needed.  The 
DOD/CALS  IGES  standard  is  preferred  for  engineering  drawings,  electronics,  and  numerical 
control.  The  standard  is  optional  for  technical  manual  illustration,  and  the  CGM  standard  is  more 
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appropriate.  The  more  comprehensive  STEP  will  provide  more  comprehensive  functionality  than 
IGES. 
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35.6  Graphics  data  interchange.  Graphics  data  interchange  is  a  collection  of  service  areas  that 
form  the  basis  for  creating  graphics.  Special  graphics  applications  such  as  found  in  Technical  Data 
Interchange  are  not  included. 

35.6.1  Raster  data  interchange.  (This  BSA  appears  in  part  3,  part  5,  and  part  6.)  Raster  data 
interchange  MIL  SPEC  identifies  the  requirements  to  be  met  when  raster  graphics  data 
represented  in  digital,  binary  format  are  delivered  to  the  government.  Raster  graphics  standards 
are  standards  for  pixel-by-pixel  representation  of  images.  (See  still  image  compression,  section 
3.5.8.2,  for  more  facsimile  standards  suitable  for  raster  data  interchange.) 

3.5.6.1.1  Standards.  Table  3.5-36  presents  standards  for  raster  data  interchange. 

TABLE  35-36  Raster  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ill 

GFC 

NIST 

User  Interface  Component  of  the  Application!  Portability 
Profile  (Adopu  the  X  Protocol,  Xlib  Interface,  Xt  Intrinsic*.  1 
and  Bitmap  Distribution  Format  of  X 11 R5) 

FIPS  PUB  158-  ! 

1:1993 

Mandated 

(Approved) 

NPC/IPC 

ANS1/ISO/IEC 

Interfacing  Technique*  for  Dialogue*  with  Graphical 
Device*  (CGI)  •  Functional  Specification  -  Part  6:  Raster 

9636-6:1991 

Mandated 

(Approved) 

GPC 

DOD  (MIMA) 

Raater  Product  Format  (RPF) 

MIL- STD- 
241  1:1994 

Mandated 

(Approved) 

PC 

ISO/IEC 

Standard  for  the  Exchange  of  Product  Model  Date  (STEP), 
Part  1:  Overview  and  Fundamental  Principle*  (formerly 
Product  Data  Exchange  Specification  (TOES)) 

10303-1:1994 

Informational 

(Approved) 

CPC 

X/Open 

X  Window  System  File  Format*  and  Application 
Conventions  (Bitmap  Distribution  Format  (BDF)) 

C170  (7/91) 

Informational 

(Approved) 

GPC 

NIST 

General  Aspects  of  Group  4  Facsimile  Apparatus  (Adopts 
BlA-536-1988) 

FtPS  PUB 
149:1988 

Informational 

(Approved) 

GPC 

NIST 

Facsimile  Coding  Schemes  and  Coding  Control  Function 
for  Group  4  Facsimile  Apparatus  (Adopt*  El  A  538- 1988) 

FIPS  PUB 
150:1988 

Informational 

(Approved) 

GPC 

NIST 

Initial  Graphic*  Exchange  Specification  (TGES)  (adopt* 
ASME/ANSI  YI4.26M-1989)  (1GES  ver.  4) 

FTPS  PUB 
177:1992 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subaets  and  IGES  Application 
Protocols 

MIL-PRF-28000 

Informational 

(Approved) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  images) 

MIL-PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

M1L-PRF-28003 

Informational 

(Approved) 

Npr 

ANSI/AIIM 

Recommended  Practice;  File  Format  for  Storage  and 
Exchange  oflmaget;  Bi-Level  Image  File  Formal:  Part  1 

MS53-1993 

Informational 

(Approved) 

GPC 

NIST 

Standard  for  the  Interchange  of  Large  Format  Tiled 
Documents 

NIST1R  88-4017 

Informational 

(Approved) 

IPC 

NATO 

Analogue  Video  Standard  for  Aircraft  System  Applications 

STANAG  3350 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specifications  for  ARC'  Standardized  Raster 
Graphics  (ASRG) 

STANAG 

4387:1996 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

NATO 

Specification  t  for  UTM/UPS  Standardized  Ratter  Product* 
(USRP) 

STANAG  7077 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Application  Profile  for  the  Interchange  of 
Formatted  Mixed  Mode  Document  -  Terminal  Equipment 
tod  Protocol  i  for  Telematic  Service# 

T.501 (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Application  Profile  for  the  Interchange  of  Group 

4  Facsimile  Document# 

T.503  (1991) 

Informational 

(Approved) 

NPC 

AJLM 

Interchange  of  Tiled  Ratter  Documents 

71114:1988 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specifications  for  ARC  Digitized  Ratter 
Graphic.  (ADRG) 

STANAG  7108 

Informational 

(Draft) 

GPC 

DOD 

Digital  Representation  for  Commaucation  of  Product 
Data:  IGES  Application  SubaeU  and  IGES  Application 
Protocol# 

MIL-D-28000A(1) 
of  12/14/92 

Informational 

(Superseded) 

GPC 

DOD 

Requirement,  for  Ratter  Graphics  Representation  in  Binary 
Format  (Group  4  Ratter  Scanned  Image#) 

MIL-R-28002B(I) 
of  9/20/1993 

Informational 

(Superseded) 

3.5.6. 1.2  Alternative  specifications.  Currently  IGES  is  the  most  mature  and  widely  implemented 
standard  for  conveying  product  data  information.  Other  bitmap  formats  include  proprietary 
formats  such  as  GIF,  PCX,  TIFF,  RLE,  and  TGA.  Except  for  support  of  legacy  products,  these 
formats  are  not  recommended. 

3.5.6. 1.3  Standards  deficiencies.  Raster  graphics  files  require  enormous  amounts  of  storage  and 
must  be  supplemented  by  compression  standards. 

325.6.1.4  Portability  caveats.  A  standard  technique  for  raster  data  interchange  should  be  selected 
for  use  throughout  the  DOD  and  applied  wherever  possible. 

3.5.6. 1.5  Related  standards.  The  following  standards  are  related  to  raster  data  interchange  or 
raster  data  interchange  standards: 

a.  ASME/ANS1  Y14.28M-1989,  which  describes  product  design  and  manufacturing 
information. 

b.  ITU-T,  facsimile  transmission  standards. 

c.  Raster  compression  standards. 

3.5.6.1.6  Recommendations.  The  mandated  standards  are  recommended  for  raster  data 
interchange. 

MIL  PRF-28002  (Raster)  can  be  used  in  a  Computer-Aided  Acquisition  and  Logistic  Support 
(CALS)  environment,  and,  when  needed,  supplemented  by  National  Institute  of  Standards  and 
Technology  Interim  Report  (NISTIR)  88-4017  (tiling).  FIPS  Pub  150  car.  also  be  used.  With 
only  the  '  ALS  Raster  standard  available,  no  real  tailoring  guidance  is  possible.  This  version 
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(MIL-PRF-28002)  supports  engineering  drawings  and  technical  manual  illustrations.  The 
previous  CALS  Raster  standard  (MIL-R-28002B)  can  be  used  for  in-place  and  unrevised  legacy 
data.  Tiling  (as  in  NISTIR  88-4017)  and  compression  are  desirable  for  very  large  raster  graphics 
files.  (See  the  Still  image  compression  BSA,  part  3.5. 8.2  of  the  ITSG.)  MIL-PRF-28003  (CGM) 
offers  the  capability  for  having  raster  and  vector  graphics  in  the  same  file.  The  approved  BDF 
provides  conventions  for  font  conversion/interchange  between  external  and  internal  X  Windows 
fonts  and  can  be  used  in  procurements  using  a  client-server  computing  architecture  with  a 
graphical  user  interface  in  a  networked  environment.  BDF  can  be  compiled  in  Server  Normal 
Format  to  be  optimized  for  a  particular  server. 
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35.6.2  Image  data  interchange.  Image  data  interchange  is  the  exchange  of  imagery  data, 
metadata,  and  attachments  to  the  images.  (See  still  image  compression  and  raster  data  interchange 
for  more  standards  suitable  for  image  data  interchange.) 

35.6.2.1  Standards.  Table  3.5-37  presents  standards  for  image  data  interchange. 


TABLE  3.5-37  Image  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

[PC 

iso/mc 

Metafile  for  Stonge/Tnnifer  of  Pictorial  Deacription 
Information  (CGM)  (u  profiled  by  FIPS  PUB  128-1  and 
MIL-STD-230I) 

8632- U, 3,4:1992 
(w/Amd  14c  2) 

Mandated 

(Anwoved) 

[PC 

iso/mc 

Digital  Compteaaion  attd  Coding  of  Continuous  -  Tone  Still 
Imaget,  Part  1 :  Requirement!  and  Guideline!  (aa  profiled 
by  MIL-STD-188-198A  -  JPEG) 

10918-1:1994 

Mandated 

(Approved) 

GPC 

DOD 

Bi-Level  Image  Comprearion 

MIL-STD-188-196 

Mandated 

(Approved) 

GPC 

Don 

Vector  Quantization  (VQ)  Decompression  for  the  NITFS 

MIL-STD-188-199 
of  6/27/1994 

Mandated 

(Approved) 

GPC 

DC;.* 

National  Imagery  Tram  mini  on  Format  veraion  2.0 

MIL-STD-2500A 

Mandated 

(Approved) 

TBD 

TBD 

JPEG  Pile  Interchange  Fonrud  (JFIF),  Version  1.02,  C- 
Cube  Microsyatema  for  raater  graphic!  data 

JFIF 

Mandated 

(Approved) 

GPC 

DOD 

National  Imagery  Tram  mil  lion  Format  Standard 

MIL-HDBK- 
1300 A 

Informational 

(Approved) 

3.5.6.2.2  Alternative  specifications.  No  alternative  specifications  exist 

35.6.2  5  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3  5.6.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  not  known. 

3.5.6.25  Related  standards.  The  remaining  National  Imagery  Transmission  Format  Standard 
(NITFS)  documents  are  related. 

3.5.6.2.6  Recommendations.  The  mandated  standards  are  recommended. 
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3 .5.6  J  Vector  graphics  data  interchange.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  6,  Graphics.)  These  standards  provide  file  formats  for  the  storage,  exchange,  and 
import/export  of  raster  or  vector  graphical  drawings  and  images. 

3.5.6.3.I  Standards.  Table  3.5-38  presents  standards  for  vector  graphics  data  interchange. 


TABLE  3.5-38  Vector  graphics  data  intercbam 

>e  standards 

Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Metafile  for  Storage/Transfer  of  Pictorial  Description 
Information  (COM)  (ai  profiled  by  FIPS  PUB  128-1  and 
MIL-STD-230n 

8632-1,2,3.4:1992 
(w/Amd  l&2) 

Mandated 

(Approved) 

NPC/IPC 

ANSl/ISO/IEC 

9592-1,2,3,4:1989 
with  AMD1:1992 

Mandated 

(Approved) 

GPC 

NIST 

Initial  Graphic*  Exchange  Specification  AGES)  (adopt* 
ASME/ANSI  Y14.26M-1989)  (ICES  ver.  4) 

FIPS  PUB 
177:1992 

Informational 

(Approved) 

NPC 

ANSI/US  PRO 

US  PRO/IPO- 100 
(Nov  1993) 

Informational 

(Approved) 

IPC 

ANS1/NPKSA 

IT8.8 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  1GES  Application  Subaet*  and  IGES  Application 
Protocol* 

MIL-PRF-28000 

informational 

(Approved) 

GPC 

DOD 

Requirement*  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL-PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

—— 

MIL-PRF-28003 

Informational 

(Approved) 

GPC 

DOD 

Computer  Graphics  Metafile  (COM)  Implementation 
Standard  for  National  Imagery  Transfer  Format  Standard 
(NITFS)  (based  on  FTPS  128) 

MIL-STD-2301A 

Informational 

(Approved) 

NPC 

ANSl/AIIM 

Recommended  Practice;  File  Format  for  Storage  and 
Exchange  of  Images;  Bi-Level  Image  File  Formal:  Part  1 

MS53-1993 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-D-28000AG) 
of  12/14/92 

Informational 

(Superseded) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

Mn--R-28002B(1) 
of  9/20/1993 

Informational 

(Superseded) 

GPC 

DOD 

iiiaiigiiiBi 

M1L-D-280O3AO) 
of  8/14/1992 

Informational 

(Superseded) 

NPC 

ANSI/AS  ME 

Digital  Representation  for  Communication  of  Product 
Definition  Data 

Y14.26M:1989 

Informational 

(Superseded) 

3.5.6.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  BMP  (Windows  Bitmap)  -  Proprietary, 

b.  CGI  (Computer  Graphics  Interface) 

c.  GIF  (Graphics  Interchange  Format)  (Used  by  CompuServe) 

d.  NAPLPS  (North  American  Presentation  Level  Protocol  Syntax) 

e.  PDL  (Page  Description  Language)  -  Proprietary 
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f.  TIFF  (Tagged  Image  File  Format)  -  Proprietary 

g.  VDM  (Virtual  Device  Metafile) 

h.  VDI  (Virtual  Device  Interface) 

35.6.3 3  Standards  deficiencies.  The  CGM  standards  have  limited  capabilities  for  handling  3-D 
geometries,  providing  fine  control  over  line  drawing  details,  and  using  font  resource  references 
enabling  reasonably  accurate  font  substitution  (the  latter  is  an  understatement),  and  describing 
color.  Several  addenda  and  amendments  are  being  developed.  The  addenda  would  add  a  global 
symbol  capability,  3-dimensional  geometry  extensions,  and  improved  engineering  drawing 
capabilities  (such  as  better  control  over  fine  details  of  line  drawings).  The  amendments  listed  in 
table  3.3-20  are  concerned  with  fonts  and  color.  These  CGM  changes  are  intended  to  be 
upwardly  compatible  with  existing  versions  of  the  specification. 

35.6.3.4  Portability  caveats.  Portability  problems  for  existing  versions  of  the  CGM  standard  are 
unknown.  Potential  portability  problems  exist  for  the  CGM  addenda  and  amendments,  as  with 
any  new  version  of  a  specification  or  product,  even  though  the  standards  groups  are  developing 
their  specifications  with  upward  compatibility  in  mind. 

35.6.35  Related  standards.  The  following  standards  are  related  to  graphics  data  exchange  or 
graphics  data  exchange  standards: 

a.  ISO  928 1 :  Identification  of  Picture  Coding  Methods. 

b.  ISO  10918-1:  Digital  Compression  and  Coding  of  Continuous  Tone  Still  Images, 
Part  1:  Requirements  and  Guidelines. 

c.  ISO  10918-2:  Digital  Compression  and  Coding  of  Continuous  Tone  Still  Images, 
Part  2:  Compliance  Testing. 

d.  ISO  CD  1 1 172:  Coding  of  Moving  Pictures  and  Associated  Audio. 

e.  ISO  SC21/WG5,  N4192:  Proposed  FTAM  Document  Type  to  Support  CGM. 

f.  ISO  SC21/WG5,  N5165:  FTAM  Constraint  Set  and  Document  Types  for  CGM. 

g.  MIL-HDBK- 1 300A,  NITFS 

h.  MIL-STD-2500A,  National  Imagery  Transmission  Format  (NITF)  Version  2.0  for 
the  NITFS. 

35.6.3.6  Recommendations.  The  mandated  standards  are  recommended. 

The  following  wording  from  the  APP  is  recommended  for  specifying  data  interchange  standards: 
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"All  computer  graphics  metafiles  acquired  to  describe,  store,  and/or  communicate  graphical 
(pictorial)  information  in  vector  format  among  different  devices,  systems,  and  installations  should 
comply  with  the  requirements  set  forth  in  FIPS  PUB  128-1,  Computer  Graphics  Metafile 
(CGM)." 

The  use  of  CGM  is  widespread,  and  many  (most)  off-the-shelf  products  for  graphics  data 
interchange  are  compatible  with  it. 

It  is  important  to  consider  the  specification  of  CGM  conformance  in  procurements  because  CGM 
is  important  to  the  integration  of  PC  applications  with  the  enterprise.  Most  PC  graphics,  word 
processing  and  desktop  publishing  programs  support  the  importing  and  exporting  of  pictures, 
bidirectionally  to  other  PC  programs  and  between  PC  and  server/minicomputer/  workstation 
applications. 
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3 .5.6.4  Color  definition.  (This  BSA  appears  in  part  5,  Data  Interchange,  part  12,  Multimedia, 
and  part  13,  Human  Factors.)  Color  definition  deals  with  establishing  a  reference  base  for 
identifying  colors  to  aid  in  the  matching  and  exchange  of  color.  Color  definition  standards  apply 
to  defining  color  in  general,  and  not  only  to  color  definition  for  information  technology  systems. 

3.5. 6.4.1  Standards.  Table  3.5-39  presents  standards  for  color  definition. 


TABLE  3.5-39  Color  definition  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ASTM 

Standaid  Test  Method  for  Computing  the  Colon  of  Objects 
by  Using  the  CIE  Syrtem 

£308(1990) 

Informational 

(Approved) 

NPC 

BA 

1976  CIE-UCS  Chromaticity  Diagram  with  Color 
Bowdarie* 

TEB26  (1988) 

Informational 

(Approved) 

[PC 

ISO 

CIE  Standard  Colorimetric  DluminanU 

CIE  10526(1991) 

Informational 

(Approved) 

IPC 

ISO 

CIE  Standard  Colorimetric  Obaerven 

CIE  10527(1991) 

Informational 

(Approved) 

IPC 

CIE 

Recommendations  on  Uniform  Color  Spaces,  Color- 
Difference  Equations,  and  Psychrometric  Color  Terms 

CIE  Pub.  15.  Suppl. 
2(1986) 

inform  atio.uU 
(Approved) 

NPC 

NPESA 

Graphic  Technology  -  Input  Data  for  Characterization  of  4- 

Color  Process  Printing 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Arti  Prepress  Definition  of  Default  RGB  Data  for 
Uae  in  the  Graphic  Arts  Industry 

IT8.7/4 

Informational 

(Approved) 

N/A 

SMPTE/EIA/VE 

SA/ISO 

Unreferenced  24-bit  RGB 

Technical  Reports 

Informational 

(Approved) 

IPC 

ISO/IEC 

Text  and  Office  System*  Colour  Architecture  (TQSCA) 

JTC1/SC18/WG5 

Informational 

(Draft) 

CPC 

ICC 

Definition  of  Named  Color 

TBD 

Infoimational 

(Formative) 

NPC 

ANSI  ro  and 
CGATS 

Specifications  for  Web  Offset  Publications  (SWOP) 

TBD 

Informational 

(Formative) 

The  CDE  (International  Commission  on  Illumination)  is  the  principal  international  standards 
writing  body  for  agreements  for  color,  vision,  and  ilium  nation.  Under  ANSI,  four  bodies  work  on 
color-related  standards.  ANSI  X3  works  on  office  docm  lent  automation  and  information  systems. 
ANSI  IT8/CGATS  is  concerned  with  graphic  arts.  ASTM  deals  with  color  metrology  and 
standard  practices,  and  SMPTE  handles  standards  for  color  television  and  color  monitors. 

ANSI's  Committee  for  Graphic  Arts  Technology  Standards  (CGATS)  has  eight  subcommittees 
working  on  topics  such  as  materials  handling,  process  control,  and  color  data  definition.  NPESA 
is  the  National  Printing  Equipment  and  Supply  Association. 

3.S.6.4.2  Alternative  specifications.  The  following  alternative  specifications  are  also  available: 
a.  Pantone  Matching  System 
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b.  RGB  (Red,  Green,  Blue)  -  the  method  directly  used  by  color  video  display 
terminals 

c.  CMYK  (Cyan,  Magenta,  Yellow,  Black)  -  used  in  four  color  printing 

d.  HSV  (Hue,  Saturation,  V.) 

e.  HSL  (Hue,  Saturation,  Luminescence) 

f.  HVC 

g.  SWOP  (Specifications  for  Web  Offset  Publications) 

h.  HSB  (Hue,  Saturation,  Brightness) 

i.  TOT  (Tag  Image  File  Format) 

3.5.6.4J  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards  assumes 
identical  viewing  conditions.  There  are  no  standards  directly  addrer'ng  comparisons  across 
viewing  environments,  although  models  are  being  worked  on.  Strict  adherence  to  correct 
presentation  and  output  standards  will  require  color  calibration  equipment 

3.5.6.4.4  Portability  caveats.  Translation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  best.  There  are  three  different  color  definitions 
from  the  CIE.  They  are  the  CIEXYZ  tristimulus  values,  and  the  CIELAB  and  C1ELUV  color 
spaces.  These  standards  have  existed  for  a  long  time  and  are  seen  as  the  common  basis  for  any 
future  unifying  definitions.  There  are  also  the  problems  of  color  matching.  For  example,  of  1 0 1 2 
Pantone  colors  for  coated  paper,  70  cannot  be  reproduced  in  the  CMYK  definition.  CIEXYZ  is 
useful  in  comparing  colors  under  identical  viewing  conditions  CIEXYZ  has  a  rigorous  definition 
and  by  itself  does  not  necessarily  constitute  a  complete  color  specification.  CIEXYZ  is  a 
standardized  set  of  primaries  which  are  not  physically  realizable  but  can  match  all  possible  colors 
with  entirely  positive  tristimulus  values.  A  new  form  of  color  definition  is  emerging,  known  as 
high-fidelity  color.  The  idea  behind  high-fidelity  color  is  the  use  of  five  to  seven  different  colors  in 
the  printing  process  to  widen  the  range  of  colors  that  can  be  printed.  Two  such  models  that  have 
appeared  are  the  Kuppcr  set  which  increases  the  number  of  printed  colors  in  the  blue  region  by 
80%,  and  the  VSF  model  which  provides  better  performance  in  deep  red  and  green  colors.  These 
processes  are  very  non-standard  and  should  be  avoided  at  present. 

Common  systems  typically  do  not  support  colorimetric  calibration. 

3.5.6.4.5  Related  standards.  The  following  types  of  standards  are  related  to  standards  for  the 
definition  of  color: 

a.  color  matching  standards 

b.  color  data  exchange  standards 
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c.  color  use  standards 

d.  style  guide  standards 

3.5.6.4.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  Maintain  original  copies  of  source  material  so  that  revisions  can  be  produced 
for  next  generation  systems  that  will  allow  the  inclusion  of  calibration  information. 
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3.5,6.5  Color  data  interchange.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  13, 
Human  Factors.)  This  BSA  deals  with  the  specific  problems  of  interchanging  data  about  color  in 
computer  graphics. 

3. 5.6. 5.1  Standards.  Table  3.5-40  presents  standards  for  color  data  interchange. 


TABLE  3.5-40  Color  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

[PC 

ISO/ffiC 

Graphic  Technology  -  Preprcai  Digital  DaU  Exchange  * 
Colour  Picture  DaU  on  Magnetic  Tape  (ANSI  IT8.1- 1988) 

10755:1992 

Informational 

(Approved) 

[PC 

ISO 

Graphic  Technology  -  Prepreai  Digital  DaU  Exchange  - 
Colour  Line  Art  DaU  on  Magnetic  Tape 

10756:1994 

Informational 

(Approved) 

UK: 

ISO 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Technology  -  Input  DaU  for  Characterization  of  4~ 
Color  Proven  Printing 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Arta  Prepreai  Definition  of  Default  RGB  DaU  for 
Ute  in  the  Graphic  Arta  Induauy 

IT8.7/4 

Informational 

(Approved) 

[PC 

1SO/IEC 

Generic  Architecture  for  Colour  DaU  Interchange 
(GACDI) 

JTC1/SC18/WG5 

Informational 

(Draft) 

The  Generic  Architecture  for  Colour  Data  Interchange  (GACDI)  standard  is  a  color  architecture 
standard  that  will  provide  a  consistent  color  framework  across  document-related  standards.  This 
standard  will  enable  users  to  interchange  color  information  in  an  open  systems  environment 
through  the  use  of  color  data  and  transform  representations. 

3.5.6.5.2  Alternative  specifications.  No  alternative  specifications  are  available. 

3.5.6.5.3  Standards  deficiencies.  There  are  no  standards  directly  addressing  comparison  across 
viewing  environments,  although  models  are  being  worked  on. 

3.5.6.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.5.6.5.5  Related  standards.  Data  interchange  standards  are  related  to  standards  for  color  data 
exchange. 

3.5.6.5.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable. 
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3.5.6.6  Color  matching.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  13,  Human 
Factors.)  This  BSA  deals  with  the  problem  of  matching  displayed  and  printed  colors  in  computer 
systems. 

3.5.6.6.1  Standards.  Table  3.5-41  presents  standards  for  color  matching. 


TABLE  35-41  Color  matching  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Graphic  Technology  •  Prepre**  Digital  Data  Exchange  • 
Online  Transfer  from  Electronic  Piepre**  Sy  item*  to 
Colour  Hardcopy  Device* 

10758:1994 

Informational 

(Approved) 

NPC 

ASTM 

Standard  Teat  Method  for  Compttfing  the  Color*  of  Object* 
by  U*ing  the  CIE  System 

E308  (1990) 

Informational 

(Approved) 

IPC 

CIE 

Recommendation*  on  Uniform  Color  Spaces,  Color- 
Difference  Equation*,  and  Ptychrometnc  Color  Term* 

CIE  Pub.  IS.Suppl. 

2  (1986) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Technology  -  Input  Data  for  Characterization  of  4- 

Color  Proceat  Printing 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Art*  Piepeus  Definition  of  Default  RGB  Data  for 
Uie  in  the  Graphic  Ait*  Indiutry 

IT8.7/4 

Inform  alional 
(Approved) 

CPC 

ICC 

ICC  Profile  Format 

ICC  Profile  Format 
ver.  3, 1994 

Informational 

(Approved) 

IPC 

tSO/EC 

Text  and  Office  System*  Colour  Architecture  (TQSCA) 

JTC1/SC18/WG5 

Informational 

(Draft) 

The  ICC  was  formed  in  March,  1994,  by  Apple,  Adobe,  Silicon  Graphics,  Taligent,  Agfa,  Kodak, 
Microsoft,  and  Sun  for  the  purpose  of  defining  profiles  for  color  handling.  The  ICC  Profile  format 
has  no  preferred  color  space,  and  provides  for  more  than  four  input  colors. 

ColorSync  Profile  Consortium  has  adopted  the  CGATS.5  specification  as  its  definition  of 
colorimetry  and  color  measurement 

The  Open  System  Color  Association  (OSCA)  has  taken  on  the  role  of  providing  industry  with  a 
centralized,  stable,  reliable,  and  common  source  of  certified  color-calibration  data.  OSCA  consists 
of  Agfa,  DuPont,  Fujifilm,  Kodak,  Radius,  3M,  and  24  other  non-founding  member  companies. 
OSCA's  work  is  in  harmony  with  the  ICC  Profile  format. 

3.5.6.6.2  Alternative  specifications.  The  following  alternative  specifications  are  also  available: 

a.  Pantone  Matching  System  (PMS) 

b.  RGB  (Red,  Green,  Blue)  -  the  method  directly  used  by  color  video  display 
terminals 

c.  CMYK  (Cyan,  Magenta,  Yellow,  Black)  -  used  in  four  color  printing 
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d.  Apple  ColorSync  2.0  (supports  ICC  and  CMYK) 

e.  Kodak  Precision  Color  Management  System  (CMS) 

f.  Electronics  for  Imaging  (EFI)  Inc.,  EFIColor 

g.  Hewlett-Packard  ColorSmart 

h.  Microsoft  Independent  Color  Matching  (ICM)  in  future  versions  of  WindowsNT 
and  Windows  95.  (accepts  ICC  Profile  Format). 

i.  Pantone  Open  Color  Environment  (POCE)  (overshadowed  by  CMS  and 
ColorSync) 

j.  Pantoi.  e  ColorDrive  (to  standardize  color  palettes) 

k.  Trumateh  SwatchPrinter 

l.  Tektronix  TekColor 

m.  Agfa-Gevaert  FotoFIow 

3J.6.6 3  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards  assumes 
identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons  across 
viewing  environments,  although  models  are  being  worked  on.  the  issue  of  where  and  how  to 
correct  color  remains  unresolved. 

3.5.6.6.4  Portability  caveats.  Translation  of  color  from  one  color  definition  s/stem  to  another 
can  be  difficult  and  is  only  an  approximation  at  best.  There  are  three  different  color  definitions 
from  the  CIE.  They  are  CIEXYZ,  CIELAB,  and  CIELUV.  These  standards  hn.ve  existed  for  a 
long  time  and  are  seen  as  the  common  basis  for  any  future  unifying  definitions 

Because  of  their  display  orientation,  all  standards  that  are  defining  computer  generated  graphics 
color,  use  RGB  models.  Most  programmers  assume  that  the  RGB  values  they  are  using  are  linear 
with  display  intensity  and  that  may  be  approximately  true  depending  on  the  response  of  the 
graphics  system.  The  actual  colors  produced  vary  according  to  the  graphics  system  used. 

3.5.6.6.5  Related  standards.  Color  ''efinition  standards  are  related  to  human  factors  standards 
for  color  matching. 

3.5.6.6.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable. 
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3.5.7  DOD  messaging.  The  following  base  service  areas  deal  with  specialized  topics  of  message 
exchange  in  real  time  tactical  systems. 


3 .5.7.1  Interchange  of  formatted  military  messages.  These  standards  specify  military  fixed  and 
variable  format  messages  used  in  the  exchange  of  tactical  information.  Most  of  the  standards  for 
formatted  military  messages  are  not  open  systems  standards  and,  therefore,  do  not  conform  to  the 
design  requirements  for  open  systems. 

3.5.7.1.1  Standards.  The  following  table  presents  the  major  DOD  joint  standards  for  the 
exchange  of  preformatted  tactical  military  messages.  Not  all  the  standards  listed  below  are  open 
systems  compliant  and,  therefore,  fall  outside  the  purview  of  this  document.  They  have  been 
included  for  completeness. 

Table  3.5-42  presents  standards  for  interchange  of  formatted  military  messages. 


TABLE  3.5-42  Interchange  of  formatted  military  messages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Message  Text  Formats  (MTF)  (NOTE  1) 

Interim  MIL -STD- 
6040  and  CJCSM 
6120.05 

Mandated 

(Approved) 

GPC 

DOD 

JEO  (TIDP-TE) 

Mandated 

(Approved) 

GPC 

DOD 

National  Imagery  Trim  million  Format  version  2.0 

MIL-STD-2500A 

Mandated 

(Approved) 

tPC 

NATO  ADSIA 

Interoperability  Standards  and  Allied  Operating  Procedures 
for  NATO  Link  16 

STANAG  5516  it 
AD  ATP- 16 

Mandated 

(Approved) 

GPC 

DOD 

MIL-STD-6011 

Informational 

(Approved) 

IPC 

NATO  ADSIA 

Interim  Joint  Tactical  Information  Distrilution  System  1 
(JTIDS)  Message  Specification  (IJMS)  ' 

UMS  Decision 
Paper  4  and  5 

Lrfoimaiionit 

(Approved) 

IPC 

NATO  ADSIA 

Interim  Joint  Tactical  Information  Distribution  System 
(JTIDS)  Message  Specification  (IJMS)  Standing  Operating 
Procedures  (SOP) 

UMS  Decision 
Paper  6 

infoimalional 

(Approved) 

GPC 

DOD  (JEO) 

Multi-TADIL  Data  Extraction  and  Reduction  Guide 
(DERG) 

JEO  DERG-Guide 

Infoimalional 

(Approved) 

GPC 

CJCS 

Joint  Multi-TADIL  Operating  Procedures  (NOTE  8) 

Joint  Pub  3-56.20 
thro  23 

Informational 

(Approved) 

GPC 

DOD 

Army  Tactical  DATA  Link-1  (ATDL-1)  Message 
Standard  (Note  6) 

M1L-STD-6013 

Informational 

(Approved) 

IPC 

NuTO  ADSIA 

NATO  Performance  Standards  and  Allied  Operating 
Procedures  for  Ship- Shore- Ship  Buffer 

STANAG  5601  Sc 
ADATP-12 

Informational 

(Approved) 

rpc 

NATO  ADSIA 

NATO  Message  Text  Format  (MTF)  and  Allied  Operating 
Procedures 

STANAG  5500  Sc 
ADATP-3 

Informational 

(Approved) 

IPC 

NATO  ADSIA 

Interoperability  Standards  and  Allied  Operating  Procedures 
for  NATO  Link  1 1 

STANAG  5501  & 
ADATP-3  i 

Infoimalional 

(Approved) 

IPC 

NATO  ADSIA  i 

Interoperability  Standards  and  Allied  Operating  Procedures 
for  NATO  Link  4 

STANAG  5504  Sc 
ADATP-4 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pm 

[PC 

NATO  ADS IA 

Interoperability  Standard*  and  Allied  Operating  Procedure* 
for  NATO  Link  11  and  1  IB 

STANAG  55114; 
ADATP-II 

Informational 

(Approved) 

IPC 

NATO  ADS  !A 

Data  Forwarding  Standard*  for  NATO  Data  Link 

STANAG  5616 

Informational 

(Draft) 

IPC 

NATO  ADSIA 

Interoperability  Standard*  for  NATO  Link  22 

STANAG  5522 

Emerging 

(Draft) 

GPC 

DOD 

Variable  Menage  Formal  (VMF)  Interface  Operating 
Procedure*  (10P) 

VMFflOP) 

Emerging 
(Partial  Draft) 

GPC 

DOD 

Tactical  Digital  Information  Link  (TADIL  C)  Menage 
Standard  (NOTE  5) 

Interim  MIL-STD- 
6004 

Iiifoimationa! 

(Draft) 

Notes: 


(1)  United  States  Message  Text  Formats  (USMTF)  provide  a  structured  format  for 
use  by  the  military  services  and  other  government  agencies.  It  is  a  character- 
oriented  message  (COM)  and  can  be  transmitted  in  record  or  voice  formats.  It  is 
used  to  transmit  down-channel,  lateral,  and  up-channel  information. 

(2)  Variable  Message  Format  (VMF)  messages  are  bit-oriented  messages  (BOM)  that 
are  used  to  exchange  information  that  is  time  sensitive  (but  not  real-time),  requires 
a  response  or  action,  and  are  machine  readable.  The  structure  of  VMF  messages 
are  designed  to  provide  specific  information  consisting  of  specific  fields.  The  VMF 
standard  continues  to  expand  under  configuration  control.  This  expansion  is 
expected  to  continue  through  FY96. 

(3)  Tactical  Data  Information  Link  (TADIL)  A  is  a  secure,  netted  data  link  using 
par?!'-'  transmission  frame  characteristics  and  standard  message  formats  at  either 

’  -  1364  bits  per  second.  TADIL  A  operates  in  the  high  frequency  (HF)  and 
ultivuigh  frequency  (UHF)  frequency  range.  TADIL  A  is  interoperable  with 
NATO  Link  11. 

(4)  TADIL  B  is  a  secure  point-to-point  data  link  utilizing  serial  transmission  frame 
characteristics  and  standard  message  formats  at  a  basic  speed  of  600  or  1200  bits 
per  second.  This  data  "nk  interconnects  tactical  air  defense  and  air  control  units. 
Message  formats  are  the  same  for  TADIL  B  and  TADIL  A.  TADIL  B  is 
interoperable  with  NATO  Link  1  IB. 

(5)  TADIL  C  is  a  time  di  '  ion  data  link  between  control  station  and  controlled 
aircraft.  It  provides  the  capability  for  automatic  transmission  of  orders,  status,  and 
other  information.  Data  exchange  is  accomplished  on  a  fully  automatic  link  at 
5000  bits  per  second,  using  serial  transmission.  TADIL  C  uses  the  UHF  frequency 
range.  TADIL  C  will  be  updated  and  republished  in  a  separate  MIL  STD  in  FY96. 
TADIL  C  is  interopei  le  with  NATO  Link  4. 
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(6)  The  Army  Tactical  Data  Link  (ATDL- 1)  is  a  point-to-point  digital  data  link  using 
serial  transmission  frame  charac'eristics  and  standard  message  formats  at  a  basic 
speed  of  600  or  1200  bits  per  second.  This  data  link  connects  tactical  air  control 
and  defense-oriented  systems. 

(7)  TADIL I  is  a  high  capacity,  secure,  jam-resistant,  nodeiess  broadcast-type  RF  data 
link  that  uses  a  time  division  multiple  access  (TDMA)  protocol.  It  provides 
information  distribution,  position  location,  and  identification  capabilities  in  an 
integrated  form  for  tactical  military  operations.  TADIL  J  uses  the  Joint  Tactical 
Information  Distribution  System  (JTIDS),  and  the  protocols,  conventions,  and 
fixed  word  message  formats  defined  by  the  JTIDS  Technical  Interface  Design  Plan 
-  Test  Edition  (TIDP-TE).  JTIDS  operates  in  the  upper  ultrahigh  frequency  Lx 
band.  TADIL  J  is  interoperable  with  NATO  Link  16. 

(8)  Joint  Multi  TADIL  Operating  Procedures  are  currently  undergoing  a  rewrite.  The 
existing  four  Joint  Publications  will  be  replaced  by  CJCSM  6120.01  with 
anticipated  distribution  in  late  FY96. 

3.5.7.1.2  Alternative  specifications.  No  other  specifications  are  available. 

35.7.1  J  Standards  deficiencies.  These  standards  have  no  known  deficiencies.  Since  these 
standards  are  configuration  managed,  any  desired  or  required  changes  to  them  must  be  approved 
through  a  formal  configuration  process  and  approved  by  a  configuration  control  board  (CCB). 

35.7.1.4  Portability  caveats.  Portability  caveats  are  not  applicable  to  these  systems. 

35.7.15  Related  standards.  No  standards  are  related  to  these  tactical,  preformatted  military 
messages. 

35.7.1.6  Recommendations.  Any  program  manager  considering  using  one  of  the  above 
standards  should  contact  JIEO,  Code  JEBC,  for  additional  information.  These  standards  are  not 
subject  to  tailoring. 
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3.5.7  2  Tactical  communications.  Tactical  communication  is  a  method  or  means  of  conveying 
information  of  any  itind,  especially  orders  and  decisions  from  one  command,  person,  or  place  to 
another  within  the  tactical  forces,  normally  by  means  of  electronic  equipment  (including 
communications  security  equipment). 

A  tactical  communication  system  is  a  system  configured  by  various  types  of  fixed-size,  self- 
contained  assemblages;  switching,  transmission,  and  terminal  equipment;  and  interconnect  and 
control  facilities  used  within  or  in  support  of  tactical  military  forces.  The  system  provides 
securable  voice  and  data  communications  among  mobile  users  to  facilitate  command  and  control. 

3.5.7.2.1  Standards.  Table  3.5-43  presents  standards  for  tactical  communications. 


TABLE  3.5-43  Tactical  communications  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Tactical  Communication  Protocol  2  (TAC02)  for  the 
National  Imagery  Trwu minion  Format  Standard  (NITFS) 

MIL- STD- 2045- 
44500  of 
6/18/1993 

Mandated 

(Approved) 

GPC 

DOD 

Mandated 

(Approved) 

GPC 

DOD 

MIL-STD- 188- 
203-3  of  10/5/88 

Informational 

(Approved) 

GPC 

DOD 

Interoperability  and  Performance  Standard*  for  Tactical 
Digital  Information  Link  (TADtL)  A  (NOTE  3) 

MIL-STD- 188- 
203A-1  of  1/8/1988 

Informational 

(Approved) 

GPC 

DOD 

Interoperability  and  Performance  Standard*  for  Tactical 
Digital  Information  Link  (TADIL)  B  (NOTE  4) 

MIL-STD- 188-2 12 
of  10/17/1992 

Informational 

(Approved) 

GPC 

DOD 

Tramport  Profile:  Reliable  End  System  Transport  for  DOD 
Communications 

MIL-STD- 2045- 
14500  Part 
LMarch  1994 

Informational 

(Approved) 

GPC 

DOD 

SIMPLEX  Transport  Profile:  CLTS  overCLNS 

■gnigaidft;» 

Informational 

(Approved) 

GPC 

DOD 

Common  Messaging 

MIL-STD-2045- 

17501 

Informational 

(Approved) 

GPC 

DOD 

Military  Messaging 

MIL-ST.i-2045- 

17502 

Informational 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profiles  -  File  Transfer,  Access  and 

Management  (FTAM)  -  Parts  1.4,  and  5  (References  ISO 

8571  pans  1-5) 

MIL-STD-2045- 
17508 -Parts  1.4. 
and  5:  7/94 

Informational 

(Approved) 

GPC 

DOD 

National  Imagery  Transmission  Format  Standard  (NITFS) 

NITFS  V.l.l 

Informational 

(Superseded) 

N1TF  standards  are  mandatory  for  secondary  imagery  systems. 

3.S.7.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 
a.  ISO  8802/3  (same  as  IEEE  802.3) 
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b.  ITU-T  1.44 1 :  Integrated  Services  Digital  Network  (ISDN)  User  Network 
Interface,  LAP-D  Data  Link  Layer  specification 

3.5.7. 2.3  Standards  deficiencies.  The  Tactical  Communication  Protocol-2  (TAC02)  protocols 
perform  well  in  half-duplex  mode  using  low-speed  and/or  dedicated  resources  and  circuits  that 
have  long  turnaround  times.  This  limits  them  to  tactical  environments  that  often  have  these 
features.  But  the  TAC02  protocols  are  not  a  substitute  for  high-level  packet  switching  protocols 
typically  found  in  networked  environments.  FED-STD-I037B  defines  point-to-point  transmission 
(i.e.,  transmission  between  two  designated  stations).  X.25  also  supports  point-to-point 
transmission. 

35.7.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.5.7.25  Related  standards.  The  following  standards  are  related  to  tactical  communications  or 
tactical  communications  standards: 

a.  ISO/IEC  International  Standardized  Profile  (ISP)  10607:  Information  Technology 
-  ISP  -  FTAM  Protocol 

b.  ISO  8571-5:  FTAM  Protocol  Implementation  Conformance  Statement  (PICS) 

c.  ISO/IEC  ISP  10611  (Draft):  Information  Technology  ISP  -  Message  Handling 
System  Comm  Messaging 

d.  MIL-HDBK- 1 300A,  NITFS 

e.  MIL-STD-2500A,  NITF  Version  2.0  for  the  NITFS 

35.7.2.6  Recommendations.  MIL-STD-2045-44500  is  recommended.  When  specifying 
communication  products  to  be  used  in  the  tactical  environment,  procurements  should  require 
products  that  support  a  commercially  available  communication  protocol  that  perform:  file 
transfers  and/or  message  transfers  with  a  variety  of  systems,  rather  than  developing  a  unique 
capability  specific  to  a  site. 
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3.5.8  Compression.  These  standards  specify  algorithms  for  compressing  data  for  storage  and 
exchange  over  a  network.  Data  compression  can  reduce  communications  loading  by  as  much  as 
80  percent  without  affecting  the  form  of  transmitted  data.  Compression  requires  application  of 
the  same  algorithms  at  the  sending  and  receiving  locations.  Compression  algorithms  for  data  must 
be  "lossless"  so  that  the  expanded  output  exactly  matches  the  original  input  Compression 
algorithms  for  images  and  audio  may  be  "lossy,"  where  some  data  may  be  lost  but  the  expanded 
output  is  not  noticeably  different  from  the  original  input 

3.5.8. 1  Text  and  data  compression.  This  service  supports  general  purpose  compression  of  any 
data,  including  text  files,  data  files,  and  executable  programs.  For  these  applications,  the 
compression  must  be  "lossless." 

3.5.8.1.1  Standards.  Table  3.5-44  presents  standards  for  text  and  data  compression. 


TABLE  3.5-44  Text  and  data  compression  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Optn 

Single  UNIX  Specification  (Spec.  1 170)  Commands  and 
Utilities,  Issue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Adopted 

(Approved) 

IPC 

ISO/IEC 

11558:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

11576:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  Interchange  -  Binary 
Arithmetic  Coding  Algorithm 

12042:1993 

Informational 

(Approved) 

NPC 

ANSI 

Compaction  Algorithm  -  Binary  Arithmetic  Coding 

X3.225 

Informational 

(Approved) 

IPC 

ECMA 

Date  Compression  for  Information  Interchange  -  Adaptive 
Coding  with  Embedded  Dictionary  -  DCLZ  Algorithm 

151 (1991) 

Informational 

(Approved) 

IPC 

ECMA 

Date  Compression  for  Information  Interchange  -  Binary 
Arithmetic  Coding  Algorithm 

159(1991) 

Informational  I 
(Approved)  | 

IPC 

ECMA 

Adaptive  Lossless  Date  Compression  Algorithm 

222(1995) 

Informational  j 
(Approved)  | 

Huffman  coding  is  a  statistical  data  compression  technique  that  substitutes  bit  strings  for  character 
strings  based  on  the  frequency  distribution  of  their  occurrence.  Strings  that  occur  more  frequently 
are  replaced  by  shorter  strings.  Huffman  coding  is  optimal  when  all  symbol  probabilities  are  an 
integral  power  of  1/2,  which  rarely  occurs. 

Arithmetic  coding  uses  a  similar  technique  for  coding  character  strings  based  on  their  frequency  of 
occurrence,  and  can  achieve  very  close  to  the  theoretical  maximum  reduction  in  message  size. 
However,  it  can  consume  large  amounts  of  computing  resources  in  terms  of  CPU  power  and 
memory. 


April  7,  1997 


3.5-90 


Version  3.1 


Information  Technology  Standards  Guidance 


Data  Interchange  Services 


Substitutional  compressors  replace  an  occurrence  of  a  particular  phrase  or  group  of  bytes  in  a 
piece  of  data  with  a  reference  to  a  previous  occurrence  of  that  phrase.  There  are  two  main  classes 
of  schemes,  named  after  Jakob  Ziv  and  Abraham  Lempel,  who  first  proposed  them  in  1977  and 
1978.  The  LZ78  based  schemes  work  by  entering  phrases  into  a  dictionary,  and  replacing  repeat 
occurrences  with  an  index  into  the  dictionary.  The  most  well  known  of  the  Lempel-Ziv  algorithms 
is  Terry  Welch's  LZW  scheme,  which  he  designed  in  1984. 

A  second  Lempel-Ziv  compression  scheme,  called  LZ77,  keeps  track  of  the  last  N  bytes  of  data 
seen,  and  when  a  repeated  phrase  is  encountered  they  output  a  pair  of  values  corresponding  to  the 
position  of  the  phrase  in  the  buffer  and  the  length  of  the  phrase.  In  effect,  the  compressor  moves  a 
fixed-size  "window"  over  the  data. 

(Note:  Much  of  the  material  in  this  section  was  derived  form  the  Frequently  Asked  Questions 
(FAQ)  in  the  Usenet  newsgroup  comp.compression.  This  file  can  be  found  on  the  World  Wide 
Web  at  http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html.) 

ISO  1 1558  describes  an  LZ78  algorithm,  while  ISO  12042  and  ANSI  X3.225  describe  arithmetic 
coding  algorithms.  The  "compress"  utility  uses  the  LZW  algorithm.  The  "pack"  utility  uses  static 
Huffman  coding.  The  "zip"  utility  and  the  compatible  MS-DOS  product  PKZ1P  use  LZ77 
compression  followed  by  static  Huffman  coding  of  the  result.  The  "gzip"  utility  uses  a  similar 
scheme.  In  addition,  the  "gunzip"  utility  can  uncompress  files  created  by  "gzip",  "zip"  "compress", 
or  "pack." 

3.5.8.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Utah  Run  Length  Encoding  (RLE):  University  of  Utah. 

b.  IFF :  Electronic  Arts. 

c.  Sun  Rasterfile:  Sun  Microsystems. 

d.  Other  proprietary  specifications  such  as  ARC,  AR7,  ARJ,  LZH,  PAK,  and  ZOO. 

e.  GNU  data  compression  utilities:  (gzip)  Free  Software  Foundation. 

f.  ZIP,  version  2.0. 1 

3.5.8.1.3  Standards  deficiencies.  None  of  the  ISO  standards  have  been  implemented  in  products. 

The  Arithmetic  algorithms  use  excessive  amounts  of  computer  resources,  and  therefore  have  not 
been  implemented  in  any  widely-used  products  or  utilities. 

The  LZ78  schemes  can  require  more  memory  than  LZ77  schemes,  which  require  only  a  fixed 
buffer. 

Huffman  coding  schemes,  such  as  used  in  "pack,”  are  not  as  efficient  as  Lempel-Ziv  coding. 
Huffman  coding  requires  that  a  substitution  table  be  transferred  before  the  compressed  data  so 
that  the  receiving  end  can  do  the  decompression.  This  adds  overhead,  particularly  for  short  files. 
An  alternative  is  to  use  a  fixed  substitution  table,  perhaps  based  on  the  frequency  of  English 
letters,  but  this  is  inefficient  for  non-text  files,  in  contrast,  the  Lempel-Ziv  substitution  algorithms 
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allow  the  receiver  to  decompress  the  output  without  receiving  any  advance  overhead  tables.  The 
dictionary,  if  used,  can  be  constructed  "on  the  fly"  from  the  received  data  stream. 

Several  Arithmetic  and  Lempel-Ziv  schemes  are  covered  by  multiple,  overlapping  patents.  Of 
note,  the  LZW  scheme,  used  in  UNIX  "compress,"  CompuServe  GIF  graphics  compression,  and 
the  V.42bis  modem  standard,  is  covered  by  patents  owned  by  IBM  and  Unisys.  The  developer  of 
the  PKZIP  product  owns  the  patent  for  one  LZ77  scheme.  Several  Arithmetic  schemes  are 
covered  by  IBM  patents,  including  the  scheme  used  in  JPEG  image  compression.  Most  of  these 
patents  cover  algorithm  implementations  rather  than  the  output  format 

3.5.8.1.4  Portability  caveats.  Although  many  compression  utilities  use  the  same  basic  algorithms, 
individual  manufacturers,  software  developers,  and  computer  services  have  adopted  their  own 
options  and  internal  storage  formats.  This  has  led  to  many  different  specifications  that  have 
incompatibilities.  A  unifying  standard  is  needed. 

3.5.8.1.5  Related  standards.  The  following  standards  are  related  to  text  and  data  compression: 

a.  ITU-T  T.8 1,  Joint  Photographic  Expert  Group  (JPEG)  standard 

b.  FIPS  170: 1992,  Data  Compression  ir.  Modems  Employing  CCITT 
Recommendation  V.42  Error  Correction. 

3.5.8. 1.6  Recommendations.  X/Open  C436  "compress"  and  "uncompress"  are  recommended. 
These  utilities  are  provided  with  almost  all  UNIX  implementations,  and  are  readily  available  for 
other  platforms.  The  "pack"  and  "unpack"  utilities  were  recommended,  and  arc  still  included  in 
the  X/Open  C436  specification,  but  X/Open  plans  to  remove  them  in  a  future  version.  Systems 
using  "pack"  should  migrate  to  "compress." 

The  Free  Software  Foundation  "gzip"  is  also  recommended.  It  is  widely  available  without  charge 
for  a  variety  of  platforms.  It  has  been  specified  for  use  as  a  standard  for  software  distribution  by 
several  DOD  software  programs. 

The  zip  file  format  is  widely  used,  especially  in  MS-DOS  environments.  Only  properly  licensed 
copies  of  the  PKZIP  utility  or  the  compatible  "zip"  utility  should  be  used.  Creators  of  compressed 
files  to  be  exchanged  between  MS-DOS  systems  are  encouraged  to  create  "self-extracting"  files 
that  can  be  distributed  and  automatically  decompressed  on  other  MS-DOS  systems  without 
license  restrictions. 
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3J5.8.2  Still  image  compression.  (This  BSA  appears  in  part  S,  Data  Interchange,  and  part  6, 
Graphics.)  Still  image  compression  standards  provide  the  capability  of  reducing  storage  needed 
for  raster  graphics  files.  This  compression  can  be  either  exact  (loss-less)  or  approximate  flossy) 
upon  reversal,  depending  upon  the  algorithm.  The  JPEG  is  interested  in  developing  standards 
covering  compression  and  decompression  of  still-frame,  continuous  tone,  photographic  (gray 
scale  or  color)  digitized  images  by  facsimile. 

3.5  JJ.2.1  Standards.  Table  3.5-45  presents  standards  for  still  image  compression. 


TABLE  3.5-45  Still  image  compression  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ni^^n 

IPC 

ISO/IEC 

Digital  Compression  and  Coding  of  Continuous  -  Tone  Still 
Images,  Past  1:  Requirements  and  Guidelines  (at  profiled 
by  MIL-STD- 1 8£-  198A  -  JPEG) 

10918-1:1994 

Mandated 

(Approved) 

GPC 

DOD 

Bi-Level  Image  Compression  for  the  National  Imageiy 
Transmission  Format  Standards  (NITFS) 

MIL-STD- 188- 196 
of  6/18/1993 

Mandated 

(Approved) 

GPC 

DOD 

Vector  Quantization  (VQ)  Decompression  for  the  NITFS 

MIL-STD- 188- 199 
of  6/27/1994 

Mandated 

(Approved) 

GPC 

NIST 

Group  3  Facsimile  Apparatus  for  Document  Transmission 

FIPS  PUB 
147:1981 

Informational 

(Approved) 

GPC 

NIST 

Procedures  for  Document  Facsimile  Transmission  (Adopts 
EIA-RS-466) 

FIPS  PUB 
148:1982 

Informational 

(Approved) 

GPC 

NIST 

General  Aspects  of  Group  4  Facsimile  Apparatus  (Adopts 
EIA-536-1988) 

FIPS  PUB 
149:1988 

Informational 

(Approved) 

GPC 

NIST 

Facsimile  Coding  Schemes  and  Coding  Control  Functions 
for  Group  4  Facsimile  Apparatus  (Adopts  EIA  538-1988) 

FIPS  PUB 
150:1988 

Informational 

(Approved) 

IPC 

ITU-T 

Standardization  of  Group  3  Facsimile  Apparatus  for 
Document  Transmission:  Terminal  Equipment  and 
Protocols  for  Telematic  Services 

T.4  (1993) 

Informational 
(Ap  woved) 

IPC 

ITU-T 

Fa*  Coding  Schemes  4  Coding  Control  Factions  for 
Group  4  Fa*  Apparatus  *  Terminal  Equipment  &  Protocols 
for  Telematic  Services 

T.6  (1989) 

Informational 
(Approved)  H 

IPC 

ITU-T 

Digital  Compression  and  Coding  of  Continuous  -  Tone  Still 
Images  -  Requirements  and  Guidelines  •  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.81  (1993) 

Informational  R 
(Approved)  1 

IPC 

ISO/IEC 

Digital  Compression  and  Coding  of  Continuous-Tone  Still 
Images  -  Part  2:  Compliance  Testing 

10918-2:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Progressive  Bi-Level  Image  Compression  (JBIG) 
Compression  Algorithm  for  Black-and- White  Images 

11544 

(Corrigendum 

1):1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  Interchange  •  Adaptive 

Coding  with  Embedded  Dictionary  -  DCLZ  Algorithm 

11558:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Procedure  for  the  Registration  of  Algorithms  for  the 

Lossless  Compression  of  Data 

11576:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  Interchange  -  Binaiy 
Arithmetic  Coding  Algorithm 

12042:1993 

Informational 

(Approved) 

IPC 

ITU-T 

Common  Components  for  Image  Compression  and 
Communication  -  Basic  Principles  -  Terminal  Equipment 
and  Protocols  for  Telematic  Services 

T.  80 (1992) 

Informational 

(Approved) 

IPC 

ITU-T 

C'oded  Representation  of  Picture  and  Audio  Information  - 
Progressive  Bi-Level  Image  Compression  -  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.82  (1993) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Requirement!  for  Rarter  Graphic!  Representation  in  Binary 
Form*!  (Group  4  Reiter  Seamed  Image*) 

MIL-PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

mu 

lc'' rotational 
(Approved) 

NPC 

ANSI 

Compaction  Algorithm  -  Binaiy  Arithmetic  Coding 

X3.225 

Informational 

(Approved) 

[PC 

ISO/IEC 

Digital  Compression  and  Coding  of  Continuous-Tcae  Still 
hnage«  •  Put  3:  Extern  tom 

10918-3:1995 

Informational 

CDr»ft) 

IPC 

ISO/EC 

Digital  Compresiion  and  Coding  of  Continuoui-Tone  Still 
Imagea  •  Registration  Procedures  for  JPEG  profile,  APPn 
maAer,  and  SPIFF  profile  ID  marker 

10918-4:1996 

Informational 

(Draft) 

IPC 

ISO/IEC 

Codsig  of  Moving  Pictured  and  Associated  Audio  for 
Digital  Storage  Media  up  to  about  1.5  Mbit/sec  (MPEG  1), 
Part  5:  Technical  Report  on  Software  for  ISO/IEC 
11172:1993 

11172-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

Genetic  Modhg  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Testing 

13818-4 

Emerging 

(Draft) 

GPC 

DOD 

Requirement*  for  Rarter  Graphics  Representation  in  Binaiy 
Format  (Group  4  Raster  Scanned  Images) 

MIL-R-28002B(I) 
of  9/20/1993 

Informational 

(Superseded) 

Nl  i'l'  standards  are  mandatory  for  Secondary  Imaging  Systems. 

3.5.8.2.2  Alternative  specifications.  The  following  compression  methods  are  also  available: 

a.  LZW  compression  algorithm. 

b.  Fractal  transforms. 

3.5.8.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.5.2.4  Portability  caveats.  The  DOD  NITFS  Adaptive  Recursive  Interpolated  Differential 
Pulse  Code  Modulation  (ARIDPCM)  compression  scheme  for  eight-bit  gray  scale  images 
eventually  will  be  replaced  by  the  ISO/JPEG  standard  in  the  broader  community,  thereby 
providing  the  potential  for  incompatibilities  with  existing  ARIDPCM-based  systems.  Fractal 
transforms  are  still  in  a  preliminary  stage  and  continue  to  present  many  problems. 

Motion  Pictures  Expert  Group  (MPEG)  is  a  joint  development  project  of  ISO  and  ITU-T.  The 
same  organization  is  responsible  for  the  JPEG  standard.  Coordination  of  the  standards  in  this 
area,  ITU-T  H.261,  JPEG,  and  MPEG  will  depend  on  ISO  and  ITU-T. 

3.5.H.2.5  Related  standards.  The  following  standards  are  related  to  non-text  data  compression 
standards: 

a.  MIL-HDBK-1300A,  NITFS 

b.  M1L-STD-2500A,  NITF  Version  2.0  for  the  NITFS 

c.  Various  multimedia  standards 
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d.  Raster  graphics  standards 

e.  ISO/IEC  11 172,  MPEG  1 

f.  ISO/IEC  13818,  MPEG2 

3.5 .8.2.6  Recommendations.  The  standards  listed  as  mandated  are  recommended.  If  the  DOD 
ARID  PCM  compression  scheme  defined  in  the  NITFS  is  specified  in  a  procurement,  a  migration 
strategy  to  the  ISO/ITU-T/JPEG  standard  also  should  be  required.  NITFS  only  supports  ITU-T 
Group  01  compression,  while  CALS  only  supports  Group  IV. 

Use  the  NITFS  compression  standards  or  CALS  compression  standard,  as  applicable.  The 
MPEG  and  Joint  Bi-Level  Imaging  Group  (JBIG)  standards  should  be  considered  for  their 
specialized  areas  of  use.  The  NIST  and  ITU-T  standards  for  facsimile  are  recommended  also. 
Lossless  versus  lossy  compression:  Group  4  facsimile  is  compatible  with  Group  3,  but  Group  3 
facsimile  is  not  necessarily  compatible  with  Group  4.  NITFS  supports  group  3,  and  CALS  MIL- 
PRF-28002  supports  group  4.  If  a  file  is  compressed  using  group  4  facsimile,  it  will  not  be 
readable  by  a  group  3  facsimile  system,  but  a  file  compressed  using  group  3  facsimile  will  be 
readable  by  a  group  4  facsimile  system. 

The  JPEG  standard  can  be  implemented  in  hardware  or  software,  and  is  already  available  in 
commercial  products.  However,  sites  purchasing  JPEG  products  based  on  the  draft  versions  of 
the  standard  should  require  vendor  assurance  that  the  products  will  comply  with  the  international 
standard. 

ITU-T  H.261  is  recommended  for  applications  that  require  a  64-Kbit/second  line  rate.  JPEG  is 
recommended  for  still  image  applications  when  its  data  loss  does  not  impact  on  the  system 
function.  MPEG  is  recommended  for  moving  image  applications  when  its  elimination  of 
redundant  information  between  frames  does  not  impact  on  the  system  function. 
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3 .5.8.3  Motion  image  compression.  '•*  ition  image  compression  standards  deal  with  moving 
pictures  coding  and  associated  audio  for  digital  storage  media. 

3. 5.8. 3.1  Standards.  Table  3.5-46  presents  standards  for  motion  image  compression. 


TABLE  3.5-46  Motion  image  compression  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

iii 

IPC 

ISO/IHC 

Codine  of  Moving  Picture*  and  Associated  Audio  for 
Digital  Storage  Media  up  to  about  1.5  Mbit/tec  (MPEG  1), 
Paii  1 :  System,  Part  2:  Video,  Part  3:  Audio  (with 
Technical  Corrigendum  1:1996) 

1 1172-  U,  3: 1993 

Mandated 

(Approved) 

IK' 

ISO/IEC 

Generic  Coding  of  Moving  Picture*  and  Associated  Audio 
information  (MPEG2).  Pttrt  1:  Systems 

13818-1:1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG2),  Part  2:  Video 

13818-2:1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Coding  of  Moving  Picture*  and  Associated  Audio  for 
Digital  Storage  Media  up  to  about  1.5  Mbit/sec  (f.iPEG  1), 
Part  4:  Conformance  Testis- 

11172-4:  1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Progressive  Bi-l  evel  Image  Compr  i.ca  (JBIG) 
Compression  Algorithm  for  Black- and- White  Images 

11544 

(Corrigendum 

1):  1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

11558:1992 

lnfonnational 

(Approved) 

IPC 

ISO/IEC 

11576:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  interchange  -  Binary 
Arithmetic  Coding  Algorithm 

12042:1993 

Inform  ational 
(Approved) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  9:  Extension  for  Real  Time 
Interface  for  Systems  Decoders 

13818-9:1996 

Informational 

(Approved) 

GPC 

NIST 

Video  Teleconferencing  Service*  at  56  to  1, 920  KB/s 
(adopts  ccnrr  H.221.  H.230.  H.242.  H.261,  and  H.320 
(all  1990)) 

FIPS  PUB 
178:1992 

Informational 

(Approved) 

IPC 

ITU-T 

Frame  Structure  for  a  64  to  1920  kttt/s  Channel  in 
Audioviiual  Teleservices  -  Line  Transmission  of  Non- 
Telephone  Signals 

H.221  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Frame-Synchronous  Control  and  Indication  Service*  for 
Audiovisual  Systems  -  Line  Transmission  of  Non- 
Telephone  Signals 

H.230.  Rev.  1 
(1990) 

Informational 

(Approved) 

IPC 

ITU-T 

System  for  Establishing  Communication  between 
Audiovisual  Terminals  Using  Digital  Channels  up  to  2 
Mbit/s 

H.242  (1993) 

Informational 

(Approved) 

ire 

ITU-T 

Video  Codec  for  Audiovisual  Services  at  p  x  64  kbit/s  - 
Line  Transmission  on  Non-Telephone  Signals  (known  as 
PX64) 

H.261  (1993) 

lnfonnational 

(Approved) 

IPC 

ITU-T 

Narrow-Band  Visual  Telephone  Systems  and  Terminal 
Equipment  •  Line  Transmission  of  Non-Telephone  Signals 

H.320  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Common  Components  for  Image  Compression  and 
Communication  -  Basi  ’‘rinciples  -  Terminal  Equipment 
and  Protocols  for  Telematic  Services 

T. 80  (1992) 

tnfoimaiionai 

(Approved) 

IPC 

ITU-T 

Digital  Compression  and  Coding  of  Continuous  -  Tone  Still 
Images  -  Requirements  and  Guidelines  -  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.81  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Coded  Representation  of  Picture  and  Audio  Information  - 
Progressive  Bi-Level  Image  Compression  -  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.82  (1993) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI 

Compaction  Algorithm  -  Binary  Arithmetic  Coding 

X3.225 

Informational 

(Approved) 

IPC 

ISO/IEC 

Coded  Representation  of  Multimedia  and  Hypermedia 
Information  Objects  (MHEG),  Multimedia  Synchronized 
and  Hypermedia  Objects 

mu 

Informational 

(Formative) 

NPC 

ANSI 

Digital  Processing  of  Video  Signals  •  Video  Oxkr/Deooder 
for  Audiovisual  Servicea  at  56  to  1,536  kbits 

T1.64 

Informational 

(Drift) 

IPC 

ISO/IEC 

Coding  of  Moving  Pictures  and  Associated  Audio  for 
Digital  Stonge  Media  up  to  about  1.5  Mbit/sec  (MPEG  I), 
Part  5:  Technical  Report  on  Software  for  ISO/lEC 
11172:1993 

11172-5 

Informational 

(Drift) 

IPC 

ISO/IEC 

Generic  Modkig  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Testing 

13818-4 

Emerging 

(Drift) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  5:  Software  Simulation 

13818-5 

Informational 

(Drift) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  6:  Extensions  for  DSM-CC 

13818-6 

Informational 

(Draft) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  7:  Audio  Extensions 

13818-7:1993 

Informational 

(Draft) 

3.S.8.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Microsoft  and  Aldus:  TIFF. 

b.  Apple:  PICT  Version  2. 

c.  Truevision,  Inc.:  TGA. 

d.  Sun  Microsystems:  Sun  Rasterfile. 

e.  Intel,  IBM,  and  AT&T:  Digital  Video  Interactive  (DV1). 

3J5.8.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

.'  1.8.3.4  Portability  caveats.  MPEG  is  a  joint  development  project  of  ISO  and  ITU-T.  The 
same  organization  is  responsible  for  the  JPEG  standard.  Coordination  of  die  standards  in  this 
ar.o,  ITU-T  H.261,  JPEG,  and  MPEG  will  depend  on  ISO  and  ITU-T. 

ISO/IEC  1 1 172-1  addresses  synchronization  and  multiplexing  of  multiple  compressed  audio  and 
video  bit  streams.  ISO/IEC  1 1 172-2  addresses  compression  of  video  signals  at  1.5  Mbits. 
ISO/IEC  1 1 172-3  addresses  compression  of  digital  audio  signals  at  rates  of  64,  128,  and  192 
kbit/s  per  channel. 

3.5.8.3.S  Related  standards.  The  following  specifications  are  related  to  motion  image 
compression  standards: 

a.  Other  compression  and  graphics  format  standards. 
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3.5. 8.3.6  Recommendations.  MPEG  is  recommended  for  moving  image  applications  when  its 
elimination  of  redundant  information  between  frames  does  not  impact  on  the  system  function. 
Selection  of  the  standard  will  depend  on  the  type  of  video-still  frames  or  full  motion  and  the  line 
rate  for  transmission.  ITU-T  H.261  is  the  international  standard  for  video  encoding  and  decoding 
at  a  64-Kbit/second  line  rate.  It  is  designed  primarily  for  use  in  the  ISDN  and  can  operate  over 
existing  digital  networks.  MPEG  compresses  video  using  a  process  called  intraframe  encoding, 
and  it  loses  some  of  the  video  during  the  encode-decode  cycle.  Compression  ratios  of  up  to  25  to 
1  can  be  used  without  a  noticeable  loss  of  image  quality.  MPEG  is  designed  specifically  for  video 
and  takes  an  asymmetrical  approach  to  compression,  dividing  the  world  of  compressed  videos 
into  publishers-producers  and  consumers-viewers.  MPEG  uses  interframe  encoding  to  eliminate 
redundant  information  between  frames.  ITU-T  H.261  is  recommended  for  applications  that  a 
require  a  64-Kbit/second  line  rate. 
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3.5. 8.4  Audio  compression.  Audio  compression  standards  deal  with  the  special  needs  of  audio 
data  in  compression. 

3. 5.8.4. 1  Standards.  Table  3.5-47  presents  standards  for  audio  compression. 


TABLE  3.5-47  Audio  compression  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

iso/mc 

Encoding  of  moving  picture*  nod  associated  Audio  for 
digit*!  storage  modi*  at  up  to  about  1.5  Mbtts/s  -• 

Part3:  Audio 

11172-3:1993 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Encoding  of  moving  picture*  and  associated  audio  for 
digital  itorage  media  at  up  to  about  1.5  Mbit*/*  -  Part  3: 
Audio  Technical  Com.tendum 

11172- 

3:1993/Cor.l:1995 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Picture*  and  Associated  Audio 
Information  (MPEG  2),  Part  3:  Audio 

13818-3:1995  with 
Amd  1 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Progressive  Bi-Level  Image  Compression  (JBIG) 
Compression  Algorithm  for  Bladt-aod- White  Image* 

11544 

(Corrigendum 

1 ):  1995 

Informational 

(Approved) 

IPC 

ITU-T 

Characteristic*  of  Compandors  for  Telephony  -  General 
Chaivrteriitic*  of  International  Telephone  Connections  and 
Circuits 

0.162(1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Characteristics  of  Syllabic  Compandors  for  Telephony  on 
High  Capacity  Long  Distance  Systems  -  General 
Characteristics  of  International  Telephone  Connections  and 
Ciicuitt 

0.166(1989) 

Informational 

(Approved) 

IPC 

ISO/IEC 

Generic  Moding  of  Moving  Picture*  and  Associated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Testing 

13818-4 

Emerging 

(Draft) 

33.8.4.2  Alternative  specifications.  Refer  to  other  compression  BSAs  for  alternatives. 

3.5.8.43  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
33.8.4.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

33.8.43  Related  standards.  Other  compression  standards  are  related. 

33.8.4.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.5.9  Data  interchange  media.  Data  interchange  media  is  a  collection  of  service  areas  for 
physical  media  used  for  data  intercha..ge. 


3.5.9. 1  Read-only  optical  disks.  Th^se  standards  are  for  optical  disks  used  for  read-only  data 
storage.  Read-only  disks  are  a  growing  means  of  distributing  software. 

3.5.9.1.1  Standards.  Table  3.5-48  presents  standards  for  read-only  optical  disks. 


TABLE  3 .5 -4b  Read-only  optical  disks  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Volume  and  Hie  structure  of  CD-ROM  for  Information 
Interchange  (same  as  ECMA  119) 

9660:1988 

Adopted 

(Approved) 

IPC 

1SO/IEC 

90mmOpL  ,1  DUk  Cartridges,  Rewritable  and  Read 
Only,  for  Dalit  Interchange  (I28MB)  (see  ECMA  154- 
1994) 

10090:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

10149:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Data  intercl.-jige  on  130  mm  optical  disk  cartridges  • 
capacity  1.3  C  bytes  per  cartridge,  CC  Servo  Format 
(ECM  A- 184  and  X3B11  Project  1001-L) 

13549:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Information  Tc>dutology  130  mm  Optical  Disk  Cartridges 
Capacity:  2  Gbytes  per  Cartridge  For  Information 
Aterchance.  (ECMA  195-1993) 

13842:1995 

Adopted 

(Approved) 

IPC 

ECMA 

Volume  and  Hie  Structure  of  CDROM  for  Information 
Interchange 

119(1987) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interchange  on  Read-Only  120  mm  Optical  Data 
Disks  (CDROM) 

130(1988) 

Informational 

(Approved) 

IPC 

am 

Data  Interchange  on  90  mm  Optical  Disk  Cartridges,  Read 
Only  and  Rewritable,  M.O. 

154(1991) 

Informational 

(Approved) 

IPC 

ECM/ 

Volume  and .  ,e  Structure  of  Read-Only  and  Wrile-Once 
Compact  Disk  Media  for  Information  Interchange 

168  (1994) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interchange  on  1 30  mm  Optical  Disk  Cartridges  • 
Capacity:  1,3  Gigabytes  per  Cartridge 

184 (1992) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Intel  '  .-•e  on  130mm  Optical  Disk  Cartridges  - 
u  ;  2  GigaBytes  per  Cartridge 

195  (1995) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interc  1 90mm  Optical  Disk  Cartridge  •  HS- 1 

Format  -  Cat  ■  6*0  Megabytes  per  Cartridge  (ISO/IEC 
D1S  15498) 

239  (1996) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interchange  on  120mm  Optical  Disk  Cartridges  using 
Phase  Change  PD  Format  -  Capacity:650  Mbytes  per 
Cartridge 

240(1996) 

Informational 

(Approved) 

NPC 

86mm,  90mm  case.  Rewritable  and  Read  Only  Optical 
Disk  Cartridge  Using  the  Discrete  Block  Formal  (DBF) 
Method  f  Xgilal  Information  Interchange  { 1 1 3MB) 

X3.213-1994 

Informational 

(Approved) 

NPC 

Test  Methodi  for  Media  Characteristics  of  90mm  (3.5") 
Rewritable/R cad- Only  Optical  Digital  Data  Disks  with 
Continuous  Composite  Servo  (CCS) 

X3.244-1995 

Informational 

(Approved) 

NPC 

ANSI  j 

Test  Metfiods  for  Media  Characteristics  of  90  mm  Read 
Only  and  Rewritable  M.O.  Optical  Disk  Data  Storage 
Cartridges  with  Discrete  Block  Format  (DBF) 

X3.246-I994 

Informational 

(Approved) 

CPC 

Various 

Digital  Video  Disk  (DVD) 

DVD 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Volume  and  Pile  Structure  of  Read-Only  and  Write- Once 
Compact  Diic  Media  for  Information  Interchange  (This  ia 
ECMA-168.) 

13490:1995 

Informational 
(Draft  (DIS)) 

tPC 

ISO/IEC 

Procedure*  for  the  Registration  of  Identifier!  and  Attribute! 
for  Volume  and  File  Structure 

13800:1994 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Interchange  for  130mm  Optical  Diik 
Cartridge!,  Capacity:  2.6  Gigabyte!  Per  Cartridge, 
Rewritable  and  Read-Only,  MO,  1,7  Modulation  ZCAV 
(mixed  mode  media) 

14517 

Informational 

(Draft) 

IPC 

ISO/IEC 

Data  Interchange  on  90  mm  Optical  Diak  Cartridge!  (640 
MB,  MO,  indudei  DOW) 

15041 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Interchange  on  90mm  Overwritabie  and  Read 
Only  Optical  Diak  Cartridge!  Uimg  Phaae  Change, 
Capadty:l,3  Gbytea  per  Cartridge  (ANSI  X3B11  Project 
1159-D 

14760 

Informational 

(Formative) 

NPC 

ANSI 

130mm  Optical  Diak  Cartridge!,  Rewritable  and  WORM 
tiling  Phase  Change  Technology  and  Emboued  Read-Only 
for  Information  Interchange  (2GB) 

X3.281 

Informational 
(Draft  (Work 
Suspended)) 

3.5.9. 1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.5.9.1.3  Standards  deficiencies.  It  is  doubtful  there  will  be  support  for  discrete  Block  Format 
(ANSI  X3.213- 1994  and  ANSI  X3.246- 1994)  in  the  future.  Other  deficiencies  in  the  existing 
standards  are  unknown. 

3.5.9.1.4  Portability  caveats.  The  following  portability  problems  have  been  identified: 

a.  ISO/IEC  9660  covers  the  logical  format  that  makes  a  Compact  Disc  readable  (see 
also  the  "Yellow  Book").  ISO/IEC  9660  is  being  revised  by  Japan's  National  Body. 
ISO/IEC  10149  covers  the  physical  characteristics  of  a  Compact  Disc  (see  also  the 
"Red  Book"). 

b.  ISO/IEC  DIS  13490  (also  known  as  The  Frankfurt  Proposal)  removes  many 
ISO/IEC  9660  restrictions,  but  is  compatible  with  ISO/IEC  9660  at  the  directory 
and  file  structure  level.  DIS  13490  includes  directory  information  required  to 
support  Unix,  supports  ISO  10646  (a  new  standard  supporting  all  the  character 
sets  of  the  world),  and  is  extendible  to  support  future  file  systems,  like  Windows 
NT.  It  also  addresses  the  logical  structure  of  data  on  a  Compact  Disc  -  Write  Once 
(CD-WO,  Orange  Book  -  Part  2)  disc,  and  is  designed  to  support  both  the  CD- 
ROM  (Yellow  Book)  and  CD-WO  conforming  media.  DIS  13490  has  been 
accepted  by  ECMA,  under  ECMA  168  CD-WO.  (Note:  ECMA  168  will  be  used 
for  the  future  CD-E  (Compact  Disc-Erasable)). 

c.  ISO/IEC  13549: 1993  introduced  the  concept  of  "mixed  mode"  media;  i.e.,  can 
combine  read-only,  write  once,  and  rewrite  functionality  on  the  same  disk. 
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d.  ISO/IEC  13842:1994  allows  for  a  reverse  spiral  on  Side  B;  allowing  for  both  sides 
to  be  read  or  written  to  simultaneously. 

e.  ISO/IEC  DIS  13800  is  being  designed  to  be  used  with  ISO  DIS  13490. 

f.  ANSI  is  recommending  cancellation  of  X3.281.  There  is  little  or  no  industry 
interest  in  continuing  work  on  this  standard.  Products  conforming  to  an  approved 
2GB  Magneto-optic  cartridge  already  exist  in  the  marketplace,  and  the  active  work 
being  done  by  X3B 1 1  is  for  higher  capacity. 

g.  Trends  in  read-only  optical  disk  standards  are  for  higher  capacities  and 
performance,  and  alternate  technologies.  The  read-only  version  of  high  density 
CDs  (Digital  Video  Disc-Read  Only  (DVD-RO))  have  a  capacity  of  4.7  GB. 

DVDs  store  information  in  data  sectors,  instead  of  along  a  spiral  as  in  the  original 
Red  Book  audio.  All  versions  of  DVD  (read-only,  rewrite,  erasable,  video  and 
games)  will  share  a  common  file  format,  a  subset  of  the  Optical  Storage 
Technology  Association  (OSTA)  Universal  Disk  Format  (UDF). 

3.S.9.1.5  Related  standards.  The  following  standards  are  related  to  read-only  optical  disks: 

a.  Red  Book  -  The  standards  for  CD-Digital  Audio,  developed  by  Philips  and  Sony, 
are  defined  in  the  "Red  Book." 

b.  Yellow  Book  -  The  standards  for  CD-ROM,  developed  by  Philips  and  Sony  and 
the  standards  for  CD-ROM/  Extended  Architecture  (XA)  developed  by  Sony, 
Philips,  and  Microsoft  are  defined  in  the  "Yellow  Book."  This  document  defines 
the  physical  properties  of  the  disc,  how  data  is  stored  and  indexed,  and  how  errors 
are  corrected. 

c.  Orange  Book  -  The  standards  for  CD-Recordable  (CD-R),  developed  by  Philips 
and  Sony,  are  defined  in  the  "Orange  Book."  This  document  standardizes  the 
physical  media  into  two  modes:  Part  1  describes  CD-Magneto-Optical  (MO)  and 
part  2  describes  CD-WO.  The  Orange  Book  specifications  re  er  to  the  physical 
standard,  while  ISO/IEC  DIS  13490  refers  to  the  logical  structure  of  data  or  a 
CD-WO  disk. 

d.  Green  Book  -  The  standards  for  CD- Interactive  (CD-I),  developed  by  Philips  and 
Sony,  are  defined  in  the  "Green  Book."  The  Green  Book  not  only  covers  the  CD-I 
disc  format,  it  also  defines  the  hardware  specifics  of  the  player  as  well,  including 
the  CPU  memory,  operating  system  (CD-RTOS-Compact  Disc  Real-Time 
Operating  System,  based  on  OS-9,  the  official  disk  operating  system  of  the  Tandy 
Color  Computer).  The  CD-I  format  synchronizes  sound,  video,  graphics,  and  text 
so  that  they  play  together  in  a  smooth,  realistic  way. 
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e.  ISO/IEC  10646-1:1993  (amendments  1-5),  Information  Technology-  Universal 
Multiple  Octet  Coded  Character  Set  (UCS)  -  Part  1:  Architecture  and  Basic 
Multilingual  Plane.  Standard  adopted  by  The  Frankfurt  Group  to  enhance  the 
Orange  Book  specifications.  ISO/IEC  10646  is  a  standard  for  using  the  many 
character  sets  of  the  world. 

35.9.1.6  Recommendations.  ISO  9660  (Volume  and  file  structure  of  CD-ROM)  is  the  standard 
recommended  for  compact  disc. 
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3S9J  Write-once  optical  disks.  These  standards  are  for  optical  disks  that  a  user  uses  to  write 
data  to  disks,  and  allows  read-only  access  to  the  recorded  data. 

3.5.9.2.1  Standards.  Table  3.5-49  presents  standards  for  write-once  optical  disks. 


TABLE  3.5-49  Write-once  optical  disks  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPO 

ISO/IEC 

130mm  (5.250  Optical  Diik  Cartridge  -  Write-Once,  for 
Information  Interchange  -  Part  I :  Unrecorded  Optical  Disk 
Cartridge 

9171-1:1990 

Adopted 

(Approved) 

IPO 

ISO/IEC 

130mm  Optical  Disk  Cartridge,  Write  Once,  for 
Information  Interchange  •  Part  2:  Recording  format  Format 
A  -  Continuous  Composite  (CC)  (ISO/IEC  version  of 
ANSI  X3.21 1)  Format  B  -  Sampled  Servo  (SS)  (ISO/IEC 
version  of  ANSI  X3.214) 

9171-2:1990 

Adopted 

(Approved) 

IPC 

ISO/IEC 

356mm  Optical  Disk  Cartridge  for  information  interchange 
-  Write  Once  (ISO/IEC  version  of  ANSI  X3.200-1992.) 

10885:1993 

Adopted 

(Approved) 

[PC 

ISO/IEC 

11 

11560:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Volume  and  Hie  Structure  of  Write -Once  and  Rewritable 
Media  Using  Non-Sequential  Recording  for  Information 
Interchange.  (ECMA  167) 

13346:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Information  Interchange  on  300 
mm  Optical  Disk  Cartridges  of  the  Write  Once,  Read 
Multiple  (WORM)  Type  using  the  CCS  Method.  (ECMA 
190) 

13403:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Data  interchange  on  130  mm  optical  disk  cartridges  - 
capacity  I  Gbytes  per  cartridge,  CC  Servo  Format. 
(ECMA- 1 83  and  X3B1 1  Project  I000-L.) 

13481:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Data  interchange  on  1 30  mm  optical  disk  cartridges  - 
capacity  1.3  Gbytes  per  cartridge,  CC  Servo  Format 
(ECMA-184  and  X3B 11  Project  10C1-D 

13549:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Information  Interchange  on  300 
mm  Optical  Disk  Cartridges  of  t1^  Write  Once,  Read 
Multiple  (WORM)  Type  using  the  SSF  Method.  (ECMA 
189) 

13614:1995 

Adopted 

(Approved) 

NPC 

ANSI 

356mm  (14.00  inch)  WORM  Optical  Disk  Cr  tridge,  Parts 
land  2 

•  X3. 200- 1992 

Adopted 

(Approved) 

NPCt* 

ANSI 

130mm  (5.25')  Write-Once  Optical  Disk  Cartridge  Using 
Continuous  Servo  RLL  2,7  Encoding  and  LCD 

X3.21 1-1992 

Adopted 

(Approved) 

NPC 

ANSI 

1 30mm  Wrile-Once  Optical  Disk  Cartridge  Using  Sampled 
Servo  and  4/15  Encoding 

X3.214-I992 

Adopted 

(Approved) 

NPC 

ANSI 

130mm  Optical  Disk  Cartridge  of  the  Wrile-Once  Read 
Multiple  (WORM)  type  Using  the  Magneto -Optical  Effect 

X  3.220- 1992 

Adopted 

(Apprved) 

NPC 

ANSI 

Recorded  Optical  Media  Unit  for  Digital  Information 
Interchange  -1 30mm  (5.25')  Write  Once  Sampled  Servo 
RZ  Selectable  Pilch  Optical  Disk  Cartridge 

X3.19I-I991 

Informational 

(Approved 

(Declining)) 

NPC 

ANSI 

356  mm  ( 14")  Optical  Disk  Cartridge  (Wrile-Once)  Test 
Methods  for  Media  Characteristics 

X3.199-1991 

Informational 

(Approved) 

IPC 

ECMA 

Volume  and  File  Structure  of  Read-Only  and  Wrile-Once 
Compact  Disk  Media  for  Information  Interchange 

168  (1994) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interchange  on  130mm  Optical  Disk  Cartridges  of 
Type  WORM  (Write Once  Read  Many)  using  irreversible 
effects  -  Capacity:  2,6  Gbytes  per  cartridge  (ISO/IEC  DIS 

238(1996) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ml 

15486) 

IPC 

ECMA 

Data  Interchange  on  12Ckiun  Optical  Ditk  Cartridge*  using 
Phate  Change  PD  Format  -  Capacity :650  Mbyte*  per 
Cartridge 

240  (1996) 

Informational 

(Approved) 

IPC 

ISO/IEC 

13490:1995 

Informational 
(Draft  (DIS)) 

IPC 

ISO/IEC 

Procedures  for  the  Regulation  of  Identifier*  and  Attribute! 
for  Volume  and  Pile  Structure 

13800:1994 

Informational 

(Draft) 

IPC 

ISO/IEC 

Infbmurion  Interchange  for  130mm  Optical  Ditk 
Cartridge*,  Capacity;  2,6  Gigabyte*  Per  Cartridge, 
Rewritable  and  Read-Only,  MO,  1,7  Modulation  ZCAV 
(mixed  mode  media) 

14517 

Informational 

(Draft) 

NPC 

ANSI 

130mm  Optical  Di*k  Cartridge*,  Rewritable  and  WORM 
Using  fhaae  Change  Technology  and  Embotted  Read-Only 
for  Information  Interchange  (2GB) 

X3.28I 

Informational 
(Draft  (Work 
Suspended)) 

NPC 

ANSI 

356  mm  Optical  Ditk  Cartridge,  Extended  Capacity,  Using 
Phase  Change  Technology,  For  Information  Interchange 
(Phase  Change  -  Write  Once  Read  Many,  PC- WORM) 

X3B11  Project 
1029-D 

Informational 

(Formative) 

CPN-C 

Toshiba 

Digital  Video  Disk- Recordable  (DVD-R)  (3.9GB) 

DVD-R 

Informational 

(Formative) 

3.5. 9.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3J.9.2.3  Standards  deficiencies.  Data  interchange  through  physical  distribution  of  optical  disks 
cannot  be  assured  with  write-oncc  technology.  ISO/1EC  9171  (130mm)  allows  for  two 
incompatible  format  types,  continuous  composite  servo  (CCS-Format  A),  and  sampled  servo 
format  (SS  or  SSF-Format  B).  A  CCS  disk  cannot  be  exchanged  with  an  SS  disk  nor  can  it  be 
read  by  an  SS  optical  drive.  Because  of  this  ANSI  established  two  separate  standards;  X3.21 1  for 
Format  A,  and  X3.214  for  Format  B.  If  system  requirements  demand  the  interchangeability  of  the 
physical  disk,  specify  the  appropriate  ANSI  standard.  There  are  currently  no  commercial 
manufacturers  producing  300mm  (12")  write-once  optical  disks  that  conform  to  either  of  the  two 
newly  ISO  adopted  standards,  ISO  13403:1995  or  ISO  13614:1995. 

ANSI  X3BU  recommended  reaffirmation  of  X3. 199: 1991  during  its  five-year  review;  however, 
drives  are  no  longer  being  manufactured,  and  this  standard  should  be  considered  declining. 

3.S.9.2.4  Portability  caveats.  The  following  portability  problems  have  been  identified: 

a.  A  standard  technique  for  write-once  optical  disks  should  be  selected  for  use 
throughout  the  DOD  and  applied  wherever  possible. 

b.  1SO/IEC  13346: 1995  is  a  new  file  system  standard  developed  through  ANSI, 
ECMA,  and  ISO.  It  supports  both  write-once  and  rewritable  functionality  and 
allows  for  unlimited  file  and  volume  sizes.  It  is  also  operating  system  independent. 
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c.  ISO/IEC  13403:1995  and  ISO/IEC  13614:1995  (300mm,  12")  both  have  the 
potential  for  a  12GB  total  capacity. 

d.  Standards  for  130mm  optical  cartridges,  ANSI  X3.21 1,  ANSI  X3.214,  ISO/IEC 
9171,  and  ISO/IEC  1 1560,  all  specify  a  storage  capacity  of  325MB  per  side 
(650MB  total). 

e.  A  new  ANSI  project  has  been  approved  (Project  1 158-D)  to  develop  the  standards 
for  130mm  Rewritable  and  Read-Only  Op  tied  Disk  Cartridge,  Capacity:  5.2  GB 
per  Cartridge  (8X),  for  Information  Interchange.  An  "I"  status  (International)  is 
being  requested  so  that  ANSI  and  ISO  efforts  will  work  in  parallel.  The  new 
standard  will  likely  provide  backward  read  and  write  compatibility  with  ISO/IEC 
DIS  14517  (2.6GB),  and  read  compatibility  (at  a  minimum)  with  ISO/IEC  13549 
(1.3GB),  and  ISO/IEC  10089  (650MB).  Backward  compatibility  to  ISO/IEC 
13842  (2GB)  is  not  expected  to  be  included  in  the  proposed  standard.  Project 

1 158-D  also  allows  for  three  sector  sizes,  512,  1024,  and  2048  bytes  per  sector. 

f.  ANSI  X3. 191  specifies  a  storage  capacity  of  1 ,28GB  for  a  double  sided  disk.  The 
cartridge  dimensions  of  ANSI  X3. 191  are  different  from  those  of  other  130mm 
Write-Once  Read  Many  (WORM)  standards,  and  optical  drives  are  no  longer 
being  produced,  ^though  this  standard  has  been  reaffirmed  during  its  five-year 
review,  optical  drives  are  no  longer  being  produced,  and  it  should  be  considered 
declining. 

g.  ANSI  X3B 1 1  Project  1029-D,  second  generation  356mm  (14")  media  standard, 
will  include  both  14.8  and  25GB  capacities  and  will  include  backward  read 
compatibility  to  ISO/IEC  10885  (6.8GB).  ISO  10885  is  expected  to  be  reaffirmed 
at  its  upcoming  five-year  review. 

h.  ANSI  X3.28 1  (X3B 1 1  Project  985-D)  uses  zone  bit  recording  (ZBR)  to  achieve 
its  capacity  of  2.0GB  per  double  sided  cartridge.  Due  to  lack  of  industry  interest, 
ANSI  is  recommending  cancellation  of  this  standard. 

i.  There  are  two  ISO  write-once  standards  for  the  12"  (300mm)  optical  disk:  ISO 
13403:1995  specifies  the  CCS  format  method  and  ISO  13614:1995  specifies  the 
SS. 

j.  ECM  A  has  approved  its  own  version  of  a  1 30mm  write-once  media  type  based  on 
that  described  in  ISO/IEC  DIS  14517  (ECMA  238  (1996))  and  has  submitted  it 
through  the  Fast  Track  procedures  as  ISO/IEC  DIS  15486. 

3.5.9.2.S  Related  standards.  The  following  standards,  proposed  standards,  and  technical  reports 
are  related  to  write-once  optical  disk  standards: 
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a.  ISO/IEC  TR  13841:1995  -  Information  Technology  -  Guidance  on  Measurement 
Techniques  for  90mm  Optical  Disk  Cartridges. 

b.  ISO/IEC  TR  1009 1 :  Information  Technology  -  Technical  aspects  of  1 30mm 
Optical  disk  cartridges  -  Write-once  Recording  Formats.  (Technical  Report, 
complement  to  ISO/IEC  9171-2  for  the  Type  A  and  B  formats.) 

c.  ABM  TR  21-1991  -  Recommendations  for  the  Identifying  Information  to  be 
Placed  on  Write-Once-Read-Many  (WORM)  and  Rewritable  Optical  Disk  (OD) 
Cartridge  Label(s)  and  Optical  Disk  Cartridge  Packaging  (Shipping  Containers) 

d.  ABM  TR  28-1991  -  Expungement  of  Information  Recorded  on  Optical  WORM 
Systems. 

e.  A  new  ANSI  project  has  been  approved  (Project  1 1 58-D)  to  develop  the  standards 
for  130mm  Rewritable  and  Read-Only  Optical  Disk  Cartridge,  Capacity:  5.2  GB 
per  Cartridge  (8X),  for  Information  Interchange.  An  "I"  status  (International)  is 
being  requested  so  that  ANSI  and  ISO  efforts  will  work  in  parallel.  This  standard 
will  likely  provide  backward  read  and  write  compatibility  with  ISO/IEC  DIS  14517 
(2.6GB),  and  read  compatibility  (at  a  minimum)  with  ISO/IEC  13549  (1.3GB), 
and  ISO/IEC  10089  (650MB).  Backward  compatibility  to  ISO/IEC  13842  (2GB) 
is  not  expected  to  be  included  in  the  proposed  standard. 

3-5.9.2.6  Recommendations.  The  recommendation  is  to  apply  the  standards  shown  above  as 
"adopted"  that  may  suit  to  the  circumstances  of  data  communication  in  the  system. 
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3.5.9  J  Rewritable  optical  disks.  These  standards  are  for  optical  disks  that  allow  the  user  to 
read,  write,  and  change  data. 

3.5.9.3.I  Standards.  Table  3.5-50  presents  standards  for  rewritable  optical  disks. 


TABLE  3.5-50  Rewritable  optical  disks  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

130mm  Rewritable  Optical  Disk  Cartridge  for  Information 
Interchange.  (ISO/IEC  venioo  of  ANSI  X3.212) 

mu 

Adopted 

(Approved) 

IPC 

ISO/IEC 

9Cknm  optical  disk  cartridge*,  rewritable  and  read  only,  for 
data  interchrmge,  (Same  ai  ECMA- 154) 

10090:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

13346:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

DaU  interchange  on  130  mm  optical  disk  cartridge* . 
capacity  1  Gbyte*  per  cartridge,  CC  Servo  Format. 
(ECMA-I83  and  X3BI 1  Proiect  1000-L.) 

13481:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Dau  interchange  on  130  mm  optical  di*k  cartridge*  • 
capacity  1.3  Gbyte*  per  cartridge,  CC  Servo  Format 
(ECMA- 1 84  and  X3B 1 1  Proiect  1 001  -L) 

13549:1993 

Adopted 

(Approved) 

IPC 

ISO/IF, C 

Information  Technology  130  mm  Optical  Disk  Cartridges 
Capacity:  2  Gbyte*  per  Cartridge  For  Information 
Interchange.  (ECMA  195-1993) 

13842:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Dau  Interchange  on  90  mm  Optical  Diak  Cartridge*  - 
Capacity:  230  MB  per  cartridge  (ECMA  201 ) 

13963:1995 

Adopted 

(Approved) 

NPC 

ANSI 

130mm  Rewritable  Optical  Diak  Cartridge  Uling  Magneto¬ 
optical  Effect  and  Continuous  Composite  Servo  Formal 

X3.2I2-I992 

Adopted 

(Approved) 

IPC 

ECMA 

223  (1995) 

Informational 

(Approved) 

IPC 

ECMA 

Dau  Interchange  on  90mm  Optical  Disk  Cartridge  -  HS- 1 
Format  -  Capacity:  650  Megabytes  per  Cartridge  (ISO/IEC 
DIS  15498) 

239  (1996) 

Informational 

(Approved) 

IPC 

ECMA 

Dau  Interchange  on  120mm  Optical  Disk  Cartridges  using 
Phase  Change  PD  Format  •  Capacity:650  Mbytes  per 
Cartridge 

240(1996) 

Informational 

(Approved) 

NPC 

ANSI 

86mm,  90mm  case,  Rewritable  and  Read  Only  Optical 
Disk  Cartridge  Using  the  Discrete  Block  Formal  (DBF) 
Method  for  Digiul  Information  Interchange  ( 1 1 3MB) 

X3.213-1994 

Informational 

(Approved) 

NPC 

ANSI 

Test  Methods  for  Media  Characteristic*  of  1 30  mm 
Rewritable  Optical  Disk  Dau  Storage  Cartridges  with 
Continuous  Composite  Servo  (CCS) 

X3.234-1993 

Informational 

(Approved) 

NPC 

ANSI 

BjjMiMHI 

X3.244-1995 

Informational 

(Approved) 

NPC 

ANSI 

Test  Methods  for  Media  Oiamcteri  sties  of  90  mm  Read 
Only  and  Rewritable  M.O.  Optical  Disk  Dau  Storage 
Cartridges  with  Discrete  Block  Format  {DBF) 

X3.246-I994 

Informational 

(Approved) 

IPC 

ISO/IEC 

DaU  Interchange  on  90  mm  Optical  Disk  Cartridges  (640 
MB.  MO,  includes  DOW) 

15041 

Informational 

(Drift) 

IPC 

ISO/IEC 

Information  Interchange  for  130mm  Optical  Disk 
Cartridges,  Capacity:  2.6  Gigabytes  Per  Cartridge, 
Rewritable  and  Read-Chily,  MO.  1,7  Modulation  ZCAV 
(mixed  mode  media) 

14517 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Interchange  on  90mm  Overwri table  and  Read 
Only  Optical  Disk  Cartridges  Using  Phase  (’hange. 
Capacity:!  .3  Gbyte*  per  Cartridge  (ANSI  X3BI  i  Project 
1159-1) 

14760 

Informational 
(Formative ) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPC 

ANSI 

130racn  Optical  Disk  Cartridges.  Rewritable  and  WORM 
Uiag  Ptuae  Change  Technology  and  Emboaaed  Read-Only 
for  Information  Intmtiacte  (2GB) 

X3.2S1 

Informational 
(Draft  (Work 
Suvended)) 

CPN-C 

Toatiiba 

Digital  Video  Diac-RewritaUe  (DVD-RAM)  (2.6GB) 

DVD-RAM 

Informational 

(Formative) 

3.S.9.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3 .5.9.3  J  Standards  deficiencies.  It  is  doubtful  there  will  be  support  for  Discrete  Block  Format 
(X3.246- 1 994)  in  the  future.  ANSI  is  recommending  cancellation  of  X3.281.  There  is  little  or  no 
industry  interest  in  continuing  work  on  this  standard.  Products  conforming  to  an  approved  2GB 
magneto-optic  cartridge  already  exist  in  the  marketplace,  and  the  active  work  being  done  by 
X3.B1 1  is  for  higher  capacity. 

3.5.9.3.4  Portability  caveats.  The  following  portability  problems  have  been  identified: 

a.  Data  interchange  through  physical  distribution  of  rewriteable  optical  disks  is  more 
standardized  than  with  write-once,  but  still  cannot  be  assured. 

b.  All  single-sided  90mm  (3.5  inch)  rewritable  optical  disks  use  the  CCS  (Continuous 
Composite  Servo)  formatting.  However,  there  are  two  methods  for  rewritability, 
magneto-optic  (MO)  which  requires  a  separate  erase  pass  before  rewriting,  and 
phase-change  rewrite  (PCR)  which  allows  for  direct  overwrite.  Two  draft 
international  standards,  ISO/IEC  DIS  14517  and  ISO/IEC  D1S  15041  both  allow 
for  Direct  Overwrite  (DOW). 

c.  ISO/IEC  10089:1991  has  been  reaffirmed  by  ANSI  X3B1 1  technical  committee  as 
a  valid  standard  during  its  five-year  review. 

d.  ISO/IEC  13549:1993  introduced  the  concept  of  "mixed  mode"  media,  i.e.,  read¬ 
only,  write  once,  and  rewrite  functionality  can  be  combined  on  the  same  disk. 

e.  A  new  ANSI  project  has  been  approved  (Project  1 158-D)  to  develop  the  standards 
for  130mm  Rewritable  and  Read-Only  Optical  Disk  Cartridge,  Capacity:  5.2  GB 
per  Cartridge  (8X),  for  Information  Interchange.  An  "I"  status  (International)  is 
being  requested  so  that  ANSI  and  ISO  efforts  will  work  in  parallel.  This  standard 
will  likely  provide  backward  read  and  write  compatibility  with  ISO/IEC  DIS  14517 
(2.6GB),  and  read  compatibility  (at  a  minimum)  with  ISO/IEC  13549  (1.3GB), 
and  ISO/IEC  10089  (650MB).  Backward  compatibility  to  ISO/IEC  13842  (2GB) 
is  not  expected  to  be  included  in  the  proposed  standard. 
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f.  ANSI  X3  Project  915-1  (ISO/IEC  D1S  15041),  Extended  Capacity  90mm 
Rewritable  Optical  Media  (640MB,  5X),  should  be  able  to  read  and  write  to 
230MB  (2X)  disks  (ISO/IEC  13963:1995). 

g.  Japanese  manufacturers  state  they  can  produce  a  "bridge  drive"  which  can 
accommodate  both  the  ?/'0MB  90mm  Magneto-Optic  and  Phase  Change  Rewrite 
(PCR)  optical  disk  cartilages;  however,  the  1,3GB  PCR  drive  will  not 
accommodate  230MB  V  disks. 

h.  A  request  has  been  made  to  make  ECMA  195  compatible  with  ISO/IEC 
13842:1995. 

i.  ANSI  X3.213  and  ISO/IEC  10090  specify  a  capacity  of  128MB  per  side.  ANSI 
X3.212.ISO/IEC  10089,  and  ISO/IEC  DIS  15498  specify  a  capacity  of  325  MB 
per  side.  ANSI  X3B 1 1  Project  9 1 5-1  will  specify  a  capacity  of  640MB  per 
cartridge. 

j.  A  standard  for  a  phase  change  multifunction  dual  drive  (PD),  which  combines 
phase  change  rewritability  (650MB  capacity)  with  quad-speed  CD-ROM  read 
funtionality  in  a  single  unit  has  been  approved  through  ECMA  (ECMA  240 
(1996). 

k.  Double  sided  90mm  optical  disks  are  being  proposed  by  industry,  which  will  have 
capacities  of  1.3GB  and  2.6GB. 

l.  ISO/IEC  10089  allows  for  both  CCS  and  SSF  formats,  which  are  incompatible 
with  each  other.  An  organization  may  have  to  use  ANSI  X3.212  to  specify  CCS 
only. 

3.S.9.3.5  Related  standards.  The  following  standards,  proposed  standards,  and  technical  reports 
are  related  to  rewritable  optical  disks: 

a.  ISO/IEC  TR 1356 1:1994  Information  Technology  -  Guidelines  for  Effective  Use 
of  ODCs  Conforming  to  ISO/IEC  10090  First  Edition. 

b.  ISO/IEC  TR13841:1995  Information  Technology  -  Guidance  on  Measurement 
Techniques  for  90mm  ODCs. 

c.  A  new  ANSI  project  has  been  approved  (Project  1 158-D)  to  develop  the  standards 
for  130mm  Rewritable  and  Read-Only  Optical  Disk  Cartridge,  Capacity:  5.2GB 
per  Cartridge  (8X),  for  Information  Interchange.  An  "I"  status  (International)  is 
being  requested  so  that  ANSI  and  ISO  efforts  will  work  in  parallel.  This  standard 
will  likely  provide  backward  read  and  write  compatibility  with  ISO/IEC  DIS  14517 
(2.6GB),  and  read  compatibility  (at  a  minimum)  with  ISO/IEC  13549  (1.3GB), 
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and  ISO/IEC  10089  (650MB).  Backward  compatibility  to  ISO/IEC  13842  (2GB) 
is  not  expected  to  be  included  in  the  proposed  standard. 

d.  X3B 1 1  Paper  95-096.  Planning  Guide  for  Third  Working  Draft  for  90mm  Phase 
Change  Optical  Disk  Cartridge,  Capacity:  1,3GB  per  Cartridge.  An  "1" 
(International)  Project  is  being  requested. 

e.  ABM  TR  21-1991  -  Recommendations  for  Identifying  Information  to  be  Placed  on 
WORM  and  Rewritable  Optical  Disk  (OD)  Cartridge  Label(s)  and  OD  Cartridge 
Packaging  (Shipping  Containers) 

3.S.9.3.6  Recommendations.  The  recommendation  is  to  apply  the  standards  shown  above  as 
"adopted"  that  may  suit  the  circumstances  of  the  system.  ISO/IEC  10090  and  10089  and  ANSI 
X3.212  are  recommended  for  rewritable  optical  disk  cartridges;  however,  future  trends  for  higher 
capacity  and  performance,  as  well  as  new  technologies,  will  soon  cause  lower 
capacity/performance  disks  to  be  outmoded.  Reaffirmation  of  ISO/IEC  10089  has  been 
recommended  by  ANSI  X3B 1 1  technical  committee  during  the  standard's  five  year  review. 
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3.S.9.4  Support  for  software  distributed  on  CD-ROM.  These  standards  provide  the  formats 
for  data  on  CD-ROM  and  the  specifications  for  drivers  to  read  them,  these  formats  are  designed 
to  deliver  finished  software  products  to  a  broad  range  of  platforms. 

3.5.9.4.1  Standards.  Table  3.5-51  presents  standards  for  support  for  software  distribution  on 
CD-ROM. 


TABLE  33-51  Support  for  software  distributed  on  CD-ROM  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Volume  and  File  itructure  of  CD-ROM  for  Information 
Interchange  (tame  as  ECMA  1 19) 

9660:1988 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Data  Interchange  on  Read-Only  12Gknm  Optical  Data 
Disks  (CD-ROM)  (»ee ECMA  130-lVSS) 

10149:1995 

Adopted 

(Approved) 

CPC 

X/Opeo 

CD-ROM  (XCDR) 

C519  (12/95) 

Informational 

(Approved) 

CPC 

IMA 

Recommended  Practice  for  DaU  Exchange  (adopts  Bento 
and  an  OMFI  subset) 

IMA-RP.  950701.1 

Informational 

(Approved) 

GPC 

DOD  (DISA) 

Department  of  Defense  Handbook,  DOD- Produced  CD- 
ROM  Products,  lit  Revision 

M1L-HDBK- 
9660A  (1996) 

Informational 

(Approved) 

CPC 

Various 

UNIPACK  (format  interface) 

PI  8,01-DO.  141 
(5/93) 

Informational 

(Approved) 

CPN-C 

Apple 

Bento  (Format  and  API) 

1.0d5,  1992 

Informational 

(Approved) 

CPN-C 

Avid 

Open  Media  Framework  Interchange  (OMFT)  format  and 
API 

OMFI,  V.  1.0,  1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Coding  of  Multimedia  and  Hypermedia  Information  -  Part 

1:  MHEG  objects  representation  -  base  notation  (ASN.l), 
Part  4:  Registration  procedure  for  MHEG  format  identifier 

13522-1,4:1995 

Informational 

(Approved) 

CPN-C 

Apple 

CD- WO  (Write  Once)  (media  interface  for  interchange) 

Orange  Book,  1993 

Informational 

(Approved) 

CPN-C 

Micro  loft 

CD-XA  (Extended  Architecture)  (media  interface  for 
interchange) 

CD-XA.  1986 

Informational 

(Approved) 

CPC 

Various 

CD-Rom  standard 

Yellow  Book,  1984 

Informational 

(Approved) 

CPC 

Various 

Digital  Video  Diik  (DVD) 

DVD 

Informational 

(Approved) 

CPC 

X/Open 

CD-ROM  Support  Component  (XCDR) 

PI20:5/9l 

Informational 

(Supeiseded) 

3.S.9.4.2  Alternative  specifications.  No  other  specifications  are  available. 


3.5.9.4.3  Standards  deficiencies.  ISO  9660  does  not  support  long  filenames  such  as  those  used 
on  UNIX  systems. 


3.S.9.4.4  Portability  caveats.  The  IMA's  Recommended  Practice  for  Data  Exchange  has  only 
recently  been  published.  Therefore,  it  is  not  broadly  supported.  It  is  designed  to  be  a  platform  and 
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content-neutral  recommendation  for  the  exchange  of  multimedia  data  for  content  and  title 
developers.  * 

Digital  Video  Disc  (DVD  also  known  as  Digital  Versatile  Disc)  will  come  in  read-only, 
recordable,  and  rewritable  forms.  DVD-RO  will  have  a  4.7GB  capacity  in  the  single  layer  version 
(a  second  layer  will  allow  for  ISO  9660  files).  DVD-R  will  have  3.9  GB  and  DVD-RAM  will  be 
2.6GB.  DVD  will  not  use  the  ISO  9660  file  format,  will  support  packet  writing  and  will  write  in 
sectors  instead  of  a  spiral.  Transfer  rates  for  DVD  will  be  about  1 .4MBps. 

3.5.9.4.5  Related  standards.  The  following  standards  are  related  to  CD-ROM: 

a.  CD-R  is  a  standard  and  technology  that  allows  a  user  to  write  to  and  read  from  a 
Compact  Disc. 

b.  CD-ROM  is  a  compact  disc  format  used  to  hold  text,  graphics,  and  stereo  sound. 

c.  CD-ROM/XA  is  a  CD-ROM  enhancement  that  allows  audio  to  be  interleaved  with 
data.  It  also  functions  as  a  bridge  between  CD-ROM  and  CD-I,  since  CD- 
ROM/XA  discs  will  play  on  a  CD-I  player.  CD-ROM/XA  uses  a  standard  CD- 
ROM  player,  but  requires  a  CD-ROM/XA  controller  card  in  the  computer. 
Although  it  is  not  a  video  specification  limited  video  can  be  included  on  disc.  To 
use  it,  you  must  have  a  drive  that  reads  the  audio  portions  of  the  disc  and  an  audio 
card  in  your  computer  that  translates  the  digital  data  into  sound.  Not  all  drives  can 
recognize  the  extensions. 

d.  CD-Video  (CD-V)  is  a  format  for  putting  five  minutes  of  video  on  a  three-inch 
disc. 

e.  CD-WO  is  a  CD-ROM  version  of  the  WORM  technology.  CD-WO  discs  conform 
to  ISO  9660  standards  and  can  be  played  in  CD-ROM  drives. 

3.5.9.4.6  Recommendations.  ISO  9660  and  10149  should  be  used  for  all  CD-ROM  applications. 
ISO  9660  describes  the  logical  structure  of  information  on  a  CD.  ISO  10149  describes  the 
physical  structure  of  the  CD.  In  addition,  MIL-HDBK-9660A,  Department  of  Defense  Handbook, 
DOD-Produced  CD-ROM  Products,  1st  Revision,  30  September  1996,  which  gives  DOD  labeling 
and  security  requirements  along  with  other  information,  should  be  followed. 

MHEG  (ISO  13522)  will  define  an  interchange  format  for  real-time  multimedia  information 
interchange.  Its  goals  are  platform  independent  interchange  of  interactive  multimedia  content, 
robust  time-space  composition  and  synchronization,  real-time  interchange,  and  incorporation  of 
arbitrary  monomedia  formats. 
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3.5.10  Data  interchange  security.  Securing  the  storage,  access,  and  transmission  of  data  to 
ensure  confidentiality  employs  a  variety  of  techniques.  These  techniques  encompass  encryption, 
data  security  labeling,  and  electronic  signatures  which  provide  non-repudiation  services. 

3.5.10.1  Systems  confidentiality.  (This  BSA  appears  in  part  5  and  part  10.)  These  standards 
provide  the  high-level  framework  with  which  to  view  the  security  service  of  confidentiality  in 
systems. 

3.5.10.1.1  Standards.  Table  3.5-52  presents  standards  for  systems  confidentiality. 


TABLE  3.5-52  Systems  confidentiality  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  System!  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

[PC 

ISO 

■Hm 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Computer  Security  Guideline*  for  Implementing  the 
Privacy  Act  of  1974 

1TPS  PUB  41:1975 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Veriion  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

[PC 

ISO/IEC 

OSI  Security  Framework*  in  Open  Syttemi,  Part  5: 

Confidentiality 

10181-5 

Informational 

(Draft) 

3.5.10.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.10.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.10.1.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.5.10.1.5  Related  standards.  DOD  5200. 1-R,  "Information  Security  Program  Regulation,"  June 
1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of  DOD 
information.  It  also  contains  DOD  policy  for  safeguarding  of  classified  information,  including 
accountability,  storage,  transmission,  and  destruction  of  the  information.  DDS-2600-6243-92, 
Compartmented  Mode  Workstation  Evaluation  Criteria,  Version  1  (final),  defines  minimum 
security  requirements  for  workstations  to  be  accredited  in  the  Compartmented  Mode  under  the 
policy  set  forth  in  DCID  1/16.  Public  Law  (PL)  93-579,  Privacy  Act  of  1974,  and  PL  100-235, 
Computer  Security  Act  of  1987,  contain  confidentiality  requirements.  FIPS  PUB  41  provides 
guidance  for  conformance  with  PL  93-579. 

3.5.10.1.6  Recommendations.  The  mandated  standard  is  recommended.  The  DGSA,  Volume  6 
of  the  TAFIM,  provides  security  principles  and  target  security  capabilities  to  guide  system 
security  architects  in  creating  specific  security  architectures  consistent  with  the  DGSA.  The 
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3.5.10.2  Data  encryption  security.  (This  BSA  appears  in  part  5,  part  7,  part  10,  and  part  1 1 .) 
Encryption  is  the  cryptographic  transformation  of  data  to  produce  cipher  text.  Standards  for  data 
encryption  security  services  describe  services  such  as  definitions/algorithms,  modes  of  operation, 
and  guidelines  for  use  for  those  systems  that  require  their  data  to  be  encrypted  using  data 
encryption  security  services.  None  of  these  standards  are  for  systems  processing  classified 
information. 

3.5.10.2.1  Standards.  Table  3.S-53  presents  standards  for  data  encryption  security. 


TABLE  3.5-53  Data  encryption  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

UPC 

NIST 

Eicrowed  Encryption  Standard  (EES) 

FIPS  PUB  185: 
1994 

Mandated 

(Approved) 

UPC 

NIST 

Dm  Encryption  Standard  (DES)  (related  to  ANSI  X3.92- 
1981/R1987/R1993) 

Bigg 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  implementation  and  tiling  the  NBS  Dale 
Encryption  Standard 

FIPS  PUB  74:1981 

Informational 

(Approved) 

GPC 

NIST 

Data  Encryption  Standard  (DES)  Mode*  of  Operation 
(related  to  ANSI  X3. 106- 1983) 

FIPS  PUB  81:1980 

Informational 

(Approved) 

GPC 

NIST 

Security  Requirement*  for  Cryptographic  Module* 

FIPS  PUB  140- 
1:1994 

Informational 

(Approved) 

IPC 

ISO 

Mode*  of  Operation  for  a  64-Bit  Block  Cipher  Algorithm 
(Related  to  ANSI  X3. 106) 

8372:1987 

Informational 

(Approved) 

NPC 

ANSI 

Data  Encryption  Algorithm 

X3. 92-1981 
(RI993) 

Informational 

(Approved) 

NPC 

ANSI 

Digital  Encryption  Algorithm  -  Mode*  of  Operation 

X3. 106- 1983 
(R1990) 

Informational 

(Approved) 

GPC 

NIST 

Advanced  Encryption  Standard 

FIPS  PUB  JJi 

Informational 

(Formative) 

3.5.10.2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary,  for 
example,  RSA. 

3.5.10.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.10.2.4  Portability  caveats.  DES  applications  are  not  portable  to  non-DES  systems. 

Portability  problems  related  to  EES  are  unknown.  The  U.S.  controls  export  of  cryptographic 
technologies,  products,  and  related  technologies  as  munitions.  On  October  1,  1996,  a  new  federal 
policy  allowing  U.S.  vendors  to  export  products  using  up  to  56-bit  encryption,  provided  the 
vendors  sign  an  agreement  to  make  their  56-bit  encryption  technologies  key-recovery-compliant 
within  24  months. 

3.5.10.2.5  Related  standards.  FIPS  PUB  1 13,  Computer  Data  Authentication,  is  related  to  Dt;S 
security  mechanisms  and  their  standards. 
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3.5.102.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  185,  EES, 
supports  lawful  authorized  access  to  the  keys  requited  to  decipher  enciphered  information  for 
systems  requiring  strong  encryption  protection  of  sensitive  but  unclassified  information.  EES 
provides  stronger  protection  than  DES  against  unauthorized  access.  Devices  conforming  to  EES 
may  be  used  when  replacing  Type  II  and  Type  in  (DES)  encryption  devices  owned  by  the 
Government  Implementations  requiring  use  of  EES  should  require  conformance  with  FIPS  PUB 
140-1. 


On  2  January  1997,  NIST  announced  pl-uis  to  develop  a  FIPS,  Advanced  Encryption  Standard, 
incorporating  an  advanced  encryption  algorithm  to  replace  DES  (FIPS  PUB  46-2). 
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3.5.10.3  Data  interchange  security  labeling.  (This  BSA  appears  in  part  S  and  part  10.)  Data 
interchange  security  labeling  provides  a  security  service  to  define  the  format  and  correctly  parse  a 
security  label  into  the  security  attributes  used  by  other  security  services. 

3.5.10.3.1  Standards.  Table  3.5-54  presents  standards  for  data  interchange  security  labeling. 


TABLE  3.5-54  Data  interchange  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

Do  I) 

(Lifecycle) 

GPC 

DOD 

Common  Security  Libel  (CSL) 

MIL-STD-2045- 
48501:  1995 

Mandated 

(Anaoved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-62 16- 
91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  liter  Interface 
Guideline!,  Revirion  1 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compaitmented  Mode  Workitation  (CMW)  Evaluation 
Criteria 

Hum 

Informational 

(Approved) 

GPC 

NIST 

Standard  Security  Label  (SSL.)  for  Information  Tramfer 

FIPS  PUB  • 
188:1994 

Informational 

(Approved) 

IPC 

m-T 

X.411: 1992 

Informational 

(Approved) 

CPC 

TSIG 

Touted  Security  Information  Exchange  for  Reitricted 
Environment! 

TSIX  (RE)  1.1 

Emerging 

(Draft) 

3.5.10.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.10.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.10.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.5.10.3.5  Related  standards.  DOD  5200.28-STD  is  a  related  standard. 

DOD  5200. 1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information. 

3.5.10.3.6  Recommendations.  The  mandated  standard  is  recommended.  TSIG  TSIX(RE)  1 . 1 
includes  options  compatible  with  MIL-STD-2045-48501. 
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3.5.10.4  Systems  non-repudiation.  (This  BSA  appears  in  part  5,  part  7,  part  10,  and  part  1 1 .) 
These  standards  provide  die  security  services  for  non-repudiation  in  systems. 

3.5.10.4.1  Standards.  Table  3.5-55  presents  standards  for  open  systems  non-repudiation. 


TABLE  3.5-55  Systems  non-repudiation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

OPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

GPC 

DOD 

Information  Technology  -  Defense  Standard  tied  Profiles 
AMHXn(D)-  Message  Handling  Systems  •  Message 
Security  Protocol  (MSP)  Parts  1-5 

MIL-STD-2045- 
18500:  1993 

Mandated 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.70I,  Rev.  3.0: 
1994 

Legacy 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701,  v.  4.0, 
Rev.  A:  1997 

Emerging 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  •  Part  I:  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  •  Part  4:  Protecting 
Transfer  Syntax  Specification 

11586-4:1994 

Informational 

(Approved) 

IPC 

ISO 

OSI  Buie  Reference  Model,  Part  2:  Security  Architecture 

(.ame  as  COTT  X. 800: 1991) 

7498-2:1989 

Informational 

(Approved) 

CPC 

IETF 

IP  Authentication  Header  (AH) 

RFC  1826:  1995 

Emerging 

(Draft) 

CPC 

OMG 

Common  Object  Request  Broker  Ardiitectuie  (CORBA) 
Security 

OMG  95-12-1: 
1995 

Emerging 

(Draft) 

CPC 

IETF 

S/MIME  Message  Specification:  PKCS  Security  Services 
for  MIME 

iin 

Informational 

(Draft) 

IPC 

1SO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Part  4:  Non- 
Repudiation  (same  u  ITU-TS  X.813) 

10181-4 

Informational 

(Draft) 

IPC 

ISO 

Non-Repudiation  Mechanisms  Part  1;  Genera]  Model 

13888-1:1992 

(SC27  N868 
(Project 
1.27.06.01)) 

informational 

(Draft) 

IPC 

ISO 

Non-Repudiation  Mechanisms  Part  2:  Using  Symmetric 
Encipherment  Algorithms 

13888-2:1994 

(SC27  N864 
(Project 
1.27.06.02)) 

Informational 

(Draft) 

IPC 

ISO 

Non-Repudiation  Mechanisms  Part  3:  Using  Asymmetric 
Techniques 

13888-3:1992 

(SC27  N869 
(Project 
1.27.06.03)) 

Informational 

(Draft) 

IPC 

ISO 

OSI  Distributed  Transaction  Processing  (DTP)  -  Draft 
Amendments  to  Parts  1  to  3:  Transaction  Processing 
Security 

WDAMs  (SC21  N 
5232  to  ISO 
10026-1.2,3)  1991 

Informational 

(Draft) 

3.5.10.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.10.4.3  Standards  deficiencies.  FIPS  186  is  for  electronic  signatures  for  unclassified  but 
sensitive  information.  It  cannot  be  used  for  classified  information. 
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3.5.10.4.4  Portability  caveats.  The  Secure  Hash  Algorithm  (SHA-1)  in  FTPS  180-1  supersedes 
the  SHA  in  FIPS  180.  SHA-1  and  SHA  are  not  interoperable;  therefore,  implementations  of  FIPS 
186  using  SHA-1  and  SHA  are  not  interoperable. 

3.5.10.4 S  Related  standards.  FIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.5. 10.4.6  Recommendations.  The  mandated  standards  are  recommended  for  non-repudiation. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement,  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

MSP  provides  for  signed  receipts.  S/MIME,  an  Internet  Draft  specification,  does  not  provide  for 
signed  receipts. 
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3.5.10.5  Electronic  signature.  (This  BSA  appears  in  part  5,  pan  7,  and  pan  1C.)  Electronic 
signature  is  the  process  that  operates  on  a  message  to  ensure  message  source  authenticity  and 
integrity,  and  source  non-repudiation.  Electronic  signatures  are  composed  so  that  the  identity  of  a 
signatory  and  integrity  of  the  data  can  be  verified. 

3.5.10.5.1  Standards.  Table  3.5-56  presents  standards  for  electronic  signature. 


TABLESjS^^EJectronicsignature^standar^ 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

DigiuJ  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

IPC 

ISO 

Digital  Signature  Scheme  Giving  Meatage  Recovery 

9796:1991 

Informational 

(Approved) 

CPC 

ETF 

Privacy  Enhancement  for  Internet  Electronic  Mail 

Informational 

(Drift) 

IPC 

ISO 

Digital  Signature  with  Appendix  •  Part  1:  General 

SC27/WG2  N294 

(Project 

1.27.08.01) 

Informational 

(Formative) 

IPC 

ISO 

Digital  Signature  with  Appendix  -  Part  2:  Identity-Bared 
Medianiimi 

SC27/WG2  N295 

(Project 

1.27.08.02) 

Inform  onal 
(Fom>  ve) 

IPC 

ISO 

Digital  Signature  with  Appendix  -  Part  3:  Certificate-Bated 
Medianiftna 

SC27/WG2  N296 

(Project 

1.27.08.03) 

Informational 

(Formative) 

3.5.105.2  Alternative  specifications.  Rivest-Shamir-Adelman  (RSA)  Public  Key  Algorithm  RC- 
5  was  developed  and  published  in  1994.  It  is  proprietary,  but  RSA  Data  Security  is  working  to 
have  it  included  in  numerous  Internet  standards.  At  present,  RC-5  is  not  recommended  for  DOD 
use  because  it  is  proprietary. 

3.5. 10.5.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.10.5.4  Portability  caveats.  DSS  applications  are  not  interoperable  with  non-DSS  systems, 

3.5.10.5.5  Related  standards.  FIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.5.10.5.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  186  is 
implemented  in  the  FORTEZZA  cryptographic  card,  a  PC  card  (formerly  called  a  Personal 
Computer  Memory  Card  International  Association  (PCMCIA)  standard  card)  that  can  be 
integrated  into  personal  computers  and  workstations  to  provide  security  in  commercial 
applications.  FORTEZZA  is  being  used  in  the  Defense  Message  System.  FIPS  PUB  186  is  the 
government-wide  key  cryptographic  signature  system. 
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3.5.10.6  Electronic  hashing.  (This  BSA  appears  in  part  5,  part  7,  part  8,  and  part  10.) 
Electronic  hashing  services  compute  a  condensed  representation  of  a  message  or  a  data  file,  often 
used  as  a  measure  of  data  integrity  checking. 

3.5.10.6.1  Standards.  Table  3.5-57  presents  standards  for  electronic  hashing. 


TABLE  3.5-57  Electronic  hashing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB  HO- 
It  1995 

Mandated 

(Approved) 

[PC 

ISO 

Huh  Function!,  Put  I:  General  Model 

101 18-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Huh  Fimctions,  Put  2:  Huh  Function*  Using  an  N-Bii 
Block  Cipher  Algorithm 

101 18-2:1994 

Informational 

(Approved) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB 
180:1993 

Informational 

(Superseded) 

IPC 

ISO 

Huh  Function*,  Pari  3:  Dedicated  Huh  Function* 

WD  10118-3, 
JTCI/SC27  N883 
(Project 
1.27.09.03) 

Informational 

(Draft) 

IPC 

ISO 

Huh  Punctiom,  Part  4:  Huh  Function*  Using  Modular 
Arithmetic 

WD  10118-4. 
JTC1/SC27  N884 
(Project 
1.27.09.04) 

Informational 

(Draft) 

3.5.10.6.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.5.10.6.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.5.10.6.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.5.10.6.5  Related  standards.  FIPS  PUB  180-1  supersedes  FIPS  PUB  180  and  is  required  for 
use  with  FIPS  PUB  186,  Digital  Signature  Standard. 

3.5.10.6.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  180-1 
specifies  SHA,  which  can  be  used  to  generate  a  message  digest.  SHA  is  required  for  use  with  the 
DSA  as  specified  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  for  federal  applications. 
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3.6  Graphics  services.  Graphics  services  provide  functions  required  for  creating  pictures  and 
importing  them  by  scanning  or  photography.  These  services  include  definition  and  management  of 
display  element  and  graphical  object  attributes.  This  includes  defining  multidimensional  graphics 
objects  in  a  form  that  is  independent  of  output  devices  and  managing  database  structures, 
including  hierarchical  and  object-oriented  structures  containing  graphics  data. 

NOTE:  Throughout  Part  6,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  IPC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3.6.1  Raster  graphics.  Raster  graphics  is  a  technique  for  representing  a  picture  image  as  a  matrix 
of  dots.  Raster  graphics  images  are  created  by  scanners  and  cameras  and  are  generated  by  paint 
packages.  The  simplest  monochrome  bitmap  uses  one  bit  (on/off)  for  each  dot.  Gray  scale  bitmaps 
(monochrome  shades)  represent  each  dot  with  a  number  large  enough  to  hold  all  the  gray  levels. 
Color  bitmaps  require  sufficient  storage  to  hold  the  intensity  of  red,  green,  and  blue  as  would  a 
grey  scale  equivalent 

3.6.1.1  Raster  data  interchange.  (This  BSA  appears  in  part  3,  part  5,  and  part  6.)  Raster  data 
interchange  MIL  SPEC  identifies  the  requirements  to  be  met  when  raster  graphics  data 
represented  in  digital,  binary  format  are  delivered  to  the  government.  Raster  graphics  standards 
are  standards  for  pixel-by-pixel  representation  of  images.  (See  still  image  compression,  section 
3.5.8.2,  for  more  facsimile  standards  suitable  for  raster  data  interchange.) 

3.6.1.1.1  Standards.  Table  3.6-1  presents  standards  for  raster  data  interchange. 


TABLE  3.6-1  Raster  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

User  Interface  Component  of  the  Applications  Portability 
Profile  (Adopts  the  X  Protocol,  Xlib  Interface,  X(  Intrinsics, 
and  Bitmap  Distribution  Formal  of  XUR5) 

FIPS  PUB  158- 

1:1993 

Mandated 

(Approved) 

NPC/IPC 

ANSI/1SO/IEC 

Interfacing  Techniques  for  Dialogues  with  Graphical 
Devices  (CGI)  -  Functional  Specification  -  Part  6:  Raster 

9636-6:1991 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Raster  Product  Formal  (RPF) 

Mandated 

(Approved) 

IPC 

ISO/1EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP). 
Part  1 :  Overview  and  Fundamental  Principles  (formerly 
Product  Daia  Exchange  Specification  (PDES)) 

10303-1:1994 

Informational 

(Approved) 

pH 

X/Open 

X  Window  System  File  Formats  and  Application 
Conventions  (Bitmap  Distribution  Formal  (BDF)) 

C170  (7/91 } 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle' 

CPC 

NIST 

Genenl  Aspect*  of  Group  4  Facsimile  Apparatus  (Adopts 
EIA-536-1988) 

FIPS  PUB 
149:1988 

Informational 

(Approved) 

GPC 

NIST 

Facsimile  Scheme!  end  Control  Rinction* 

for  Group  4  Facsimile  Apparatus  (Adopt!  EIA  538-1988) 

FIPS  PUB 
150:1988 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB 
177:1992 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Commtaucatioo  of  Product 
Data:  IGES  Application  SubeeU  and  IGES  Application 
Protocol! 

MIL-PRF-28000 

Informational 

(Approved) 

GPC 

DOD 

Requirement!  for  Rader  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Image*) 

MIL-PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

MIL-PRF-28003 

Informational 

(Approved) 

NPC 

ANSI/AIIM 

Recommended  Practice;  Hie  Format  for  Storage  and 
Exchange  of  Imagea;  Bi-Level  Image  File  Format:  Part  1 

MS53-I993 

Informational 

(Approved) 

GPC 

NIST 

Standard  for  the  Interchange  of  Large  Format  Tiled 
Documents 

N1STIR  88-4017 

Informational 

(Approved) 

IPC 

NATO 

Analogue  Video  Standard  for  Aircraft  System  Application! 

STANAG  3350 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specification*  for  ARC  Standardized  Ratter 
Graphic*  (ASRG) 

STANAG 

4387:1996 

Informational 

(Approved) 

IPC 

NATO 

Specification*  for  UTM/UPS  Standardized  Raiter  Products 
(USRP) 

STANAG  7077 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Application  Profile  for  the  Interchange  of 
Formatted  Mixed  Mode  Document  •  Terminal  Equipment 
and  Protocol!  for  Telematic  Service! 

T.501  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Application  Profile  for  the  Interchange  of  Group 

4  Facsimile  Document* 

T.503  (1991) 

Informational 

(Approved) 

NPC 

AIIM 

Interchange  of  Tiled  Raster  Document! 

TR 14: 1988 

Informational 

(Approved) 

IPC 

NATO 

Exchange  Specifications  for  ARC  Digitized  Raster 
Graphics  (ADRG) 

STANAG  7 108 

Informational 

(Draft) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-D-28000A(l) 
of  12/14/92 

Informational 

(Superseded) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Ruler  Scanned  Images) 

MIL-R-28002B(  1 ) 
of  9/20/1993 

Informational 

(Superseded) 

3.6.1. 1.2  Alternative  specifications.  Currently  IGES  is  the  most  mature  and  widely  implemented 
standard  for  conveying  product  data  information.  Other  bitmap  formats  include  proprietary 
formats  such  as  GIF,  PCX,  TIFF,  RLE,  and  TGA.  Except  for  support  of  legacy  products,  these 
formats  are  not  recommended. 


3.6. 1.1.3  Standards  deficiencies.  Raster  graphics  files  require  enormous  amounts  of  storage  and 
must  be  supplemented  by  compression  standards. 

3.6.1. 1.4  Portability  caveats.  A  standard  technique  for  raster  data  interchange  should  be  selected 
for  use  throughout  the  Department  of  Defense  (DOD)  and  applied  wherever  possible. 
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3.6. 1.1.5  Related  standards.  The  following  standards  are  related  to  raster  data  interchange  or 
raster  data  interchange  standards: 

a.  ASME/ANSI  Y14.28M-1989,  which  describes  product  design  and  manufacturing 
information. 

b.  ITU-T,  facsimile  transmission  standards. 

c.  Raster  compression  standards. 

3.6.1.1.6  Recommendations.  The  mandated  standards  are  recommended  for  raster  data 
interchange. 

MIL  PRF-28002  (Raster)  can  be  used  in  a  Computer-Aided  Acquisition  and  Logistic  Support 
(CALS)  environment,  and,  when  needed,  supplemented  by  National  Institute  of  Standards  and 
Technology  Interim  Report  (NISTIR)  88-4017  (tiling).  FIPS  Pub  150  can  also  be  used.  With 
only  the  CALS  Raster  standard  available,  no  real  tailoring  guidance  is  possible.  This  version 
(MIL-PRF-28002)  supports  engineering  drawings  and  technical  manual  illustrations.  The 
previous  CALS  Raster  standard  (MIL-R-28002B)  can  be  used  for  in-place  and  unrevised  legacy 
data.  Tiling  (as  in  NISTIR  88-4017)  and  compression  are  desirable  for  very  large  raster  graphics 
files.  (See  the  Still  image  compression  BSA,  part  3.S.8.2  of  the  ITSG.)  MIL-PRF-28003  (CGM) 
offers  the  capability  for  having  raster  and  vector  graphics  in  the  same  file.  The  approved  BDF 
provides  conventions  for  font  conversion/interchange  between  external  and  internal  X  Windows 
fonts  and  can  be  used  in  procurements  using  a  client-server  computing  architecture  with  a 
graphical  user  interface  in  a  networked  environment.  BDF  can  be  compiled  in  Server  Normal 
Format  to  be  optimized  for  a  particular  server. 
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3.6.1.2  Still  image  compression.  (This  BSA  appears  in  part  S,  Data  Interchange,  and  part  6, 
Graphics.)  Still  image  compression  standards  provide  the  capability  of  reducing  storage  needed 
for  raster  graphics  files.  This  compression  can  be  either  exact  (loss-)ess)  or  approximate  flossy) 
upon  reversal,  depending  upon  the  algorithm.  The  JPEG  is  interested  in  developing  standards 
covering  compression  and  decompression  of  still-frame,  continuous  tone,  photographic  (gray 
scale  or  color)  digitized  images  by  facsimile. 

3.6.I.2.1  Standards.  Table  3.6-2  presents  standards  for  still  image  compression. 


TABLE  3.6-2  Still  image  compression  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

miim 

DPC 

ISO/IEC 

Digital  Compression  and  Coding  of  Continuous  -  Tone  Still 
Images,  Part  I:  Requirements  and  Guidelines  (as  profiled 
bv  MIL-STD-I88-198A  -  JPEG) 

10918-1:1994 

Mandated 

(Approved) 

GPC 

DOD 

Bi-Level  Image  Compression  for  the  National  Imagery 
Transmission  Format  Standards  (NITFS) 

M1L-STD-188-196 
of  6/18/1993 

Mandated 

(Approved) 

GPC 

DOD 

Vector  Quantization  (VQ)  Decompression  for  the  NITFS 

MIL-STD-188-199 
of  6/27/1994 

Mandated 

(Approved) 

GPC 

NIST 

Group  3  Facsimile  Apparatus  for  Document  Transmission 

FIPS  PUB 
147:1981 

Informational 

(Approved) 

GPC 

NIST 

Procedures  for  Document  Facsimile  Transmission  (Adopts 
ElA-RS-466) 

FIPS  PUB 
148:1982 

Informational 

(Approved) 

GPC 

NIST 

General  Aspects  of  Group  4  Facsimile  Apparatus  (Adopts 
EIA-536-1988) 

FIPS  PUB 
149:1988 

Informational 

(Approved) 

GPC 

NIST 

Facsimile  Coding  Schemes  and  Coding  Control  Functions 
for  Group  4  Facsimile  Apparatus  ( Adopts  El  A  538- 1988) 

FIPS  PUB 
150:1988 

Informational 

(Approved) 

IPC 

rru-T 

Standardization  of  Group  3  Facsimile  Apparatus  for 
Document  Transmission:  Terminal  Equipment  and 
Protocols  for  Telematic  Services 

T.4  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Fax  Ceding  Schemes  &  Coding  Control  Functions  for 
Group  4  Fax  Apparatus  -  Terminal  Equipment  &  Protocols 
for  Telematic  Services 

T.6  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Digital  Compression  and  Coding  of  Continuous  •  Tone  Still 
Images  -  Requirements  and  Guidelines  •  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.81  (1993) 

Informational 

(Approved) 

IPC 

ISO/IEC 

Digital  Compression  and  Coding  of  Continuous-Tone  Still 
Images  -  Part  2:  Compliance  Testing 

10918-2:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Progressive  Bi-Level  Image  Compression  (JBIG) 
Compression  Algorithm  for  Black-and- White  Images 

11544 

(Corrigendum 

1):  1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  Interchange  -  Adaptive 
Coding  with  Embedded  Dictionaty  -  DCLZ  Algori'hm 

11558:1992 

Informational 

(Approved) 

ipc 

ISO/IEC 

11576:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Data  Compression  for  Information  Interchange  -  Binary 
Arithmetic  Coding  Algorithm 

12042:1993 

Informational 

(Approved) 

IPC 

ITU-T 

Common  Components  for  Image  Compression  and 
Communication  -  Basic  Principles  -  Terminal  Equipment 
and  Protocols  for  Telematic  Services 

T.80 (1992) 

Informational 

(Approved) 

IPC 

ITU-T 

Coded  Representation  of  Picture  and  Audio  Information  - 
Progressive  Bi-Level  Image  Compression  -  Terminal 
Equipment  and  Protocols  for  Telematic  Services 

T.82  (1993) 

Informational 

(Approved) 

3.6-4 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Requirement*  for  Rader  Graphics  Reprroentation  in  Binary 
Format  (Group  4  Ratter  Seamed  Image*) 

MIL-PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

MIL-STD-18S- 

197A  of 
10/12/1994 

Informational 

(Approved) 

NPC 

ANSI 

Compaction  Algorithm  •  Binary  Arithmetic  Coding 

X3.225 

Informational 

(Approved) 

IPC 

ISO/IEC 

Digital  Compreuion  and  Coding  of  Cootinuoui-Tooe  Still 
Image*  -  Part  3:  Ejrtreuioni 

10918-3:1995 

Informational 

(Draft) 

IPC 

ISO/IEC 

Digital  Compreuion  and  Coding  of  Continuou*-Tone  Still 
Image*  -  Regulation  Procedure*  for  JPEG  profile,  APPn 
marker,  and  SPIFT  profile  ID  marker 

10918-4:1996 

Informational 

(Draft) 

IPC 

ISO/IEC 

Coding  of  Moving  Picture*  and  Aatodated  Audio  for 
Digital  Storage  Media  up  to  about  1.5  Mbil/tec  (MPEG  1), 
Part  5:  Technical  Report  on  Software  for  ISO/IEC 
11172:1993 

11172-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

Generic  Moding  of  Moving  Picture*  and  Aitociated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Tearing 

13818-4 

Emerging 

(Draft) 

GPC 

DOD 

Requirement!  for  Rader  Graphic*  Representation  in  Binary 
Format  (Group  4  Rader  Scanned  Image*) 

MIL-R-28002B(1) 
of  9/20/1993 

Informational 

(Superseded) 

3.6.1.2.2  Alternative  specifications.  The  following  compression  methods  are  also  available: 

a.  LZW  compression  algorithm. 

b.  Fractal  transforms. 

3.6. 1.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.6.1.2.4  Portability  caveats.  The  DOD  National  Imagery  Transfer  Format  Standards  (NITFS) 
Adaptive  Recursive  Interpolated  Differential  Pulse  Code  Modulation  (ARIDPCM)  compression 
scheme  for  eight-bit  gray  scale  images  eventually  will  be  replaced  by  the  International 
Organization  for  Standardization  (ISO)/JPEG  standard  in  the  broader  community,  thereby 
providing  the  potential  for  incompatibilities  with  existing  AREDPCM-based  systems.  Fractal 
transforms  are  still  in  a  preliminary  stage  and  continue  to  present  many  problems. 

Motion  Pictures  Expert  Group  (MPEG)  is  a  joint  development  project  of  ISO  and  ITU-T.  The 
same  organization  is  responsible  for  the  JPEG  standard.  Coordination  of  the  standards  in  this 
area,  ITU-T  H.261,  JPEG,  and  MPEG  will  depend  on  ISO  and  ITU-T. 

3.6.1.2.5  Related  standards.  The  following  standards  are  related  to  non-text  data  compression 
standards: 

a.  MIL-HDBK-1300A,  NITFS 

b.  MIL-STD-2500A,  NITF  Version  2.0  for  the  NITFS 

c.  Various  multimedia  standards 

d.  Raster  graphics  standards 
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e.  ISO/IEC  1 1 172,  MPEG1 

f.  ISO/IEC  13818,  MPEG2 

3.6. 1.2.6  Recommendations.  The  standards  listed  as  mandated  are  recommended.  If  the  DOD 
ARID  PCM  compression  scheme  defined  in  the  NITFS  is  specified  in  a  procurement,  a  migration 
strategy  to  the  ISO/TTU-T/JPEG  standard  also  should  be  required.  NITFS  only  supports  ITU-T 
Group  HI  compression,  while  CALS  only  supports  Group  IV. 

Use  the  NITFS  compression  standards  or  CALS  compression  standard,  as  applicable.  The 
MPEG  and  Joint  Bi-Level  imaging  Group  (JBIG)  standards  should  be  considered  for  their 
specialized  areas  of  use.  The  NIST  and  ITU-T  standards  for  facsimile  are  recommended  also. 
Lossless  versus  lossy  compression:  Group  4  facsimile  is  compatible  with  Group  3,  but  Group  3 
facsimile  is  not  necessarily  compatible  with  Group  4.  NITFS  supports  group  3,  and  CALS  MIL- 
PRF-28002  supports  group  4.  If  a  file  is  compressed  using  group  4  facsimile,  it  will  not  be 
readable  by  a  group  3  facsimile  system,  but  a.  file  compressed  using  group  3  facsimile  will  be 
readable  by  a  group  4  facsimile  system. 

The  JPEG  standard  can  be  implemented  in  hardware  or  software,  and  is  already  available  in 
commercial  products.  However,  sites  purchasing  JPEG  products  based  on  the  draft  versions  of 
the  standard  should  require  vendor  assurance  that  the  products  will  comply  with  the  international 
standard. 

• 

ITU-T  H.261  is  recommended  for  applications  that  require  a  64-Kbil/second  line  rate.  JPEG  is 
recommended  for  still  image  applications  when  its  data  loss  does  not  impact  on  the  system 
function.  MPEG  is  recommended  for  moving  image  applications  when  its  elimination  of 
redundant  information  between  frames  does  not  impact  on  the  system  function. 
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3.6.2  Vector  graphics.  Vector  graphics  are  a  method  of  representing  graphical  objects  as  sets  of 
endpoints  for  lines,  curves,  and  other  geometric  shapes  with  data  about  width,  color,  and  spaces 
bounded  by  lines  and  curves.  The  entire  image  commonly  is  stored  in  the  computer  as  a  list  of 
vectors  called  a  display  list  Vector  graphics  are  used  when  you  need  geometric  knowledge  about 
the  object  created.  Geometric  shapes  keep  their  integrity:  a  line  always  can  be  picked,  extended, 
or  erased.  Today,  most  screens  are  raster  graphics  displays  (composed  of  dots),  and  the  vectors 
are  put  into  the  required  dot  patterns  (rasters)  by  hardware  or  software.  Vector  graphics  systems 
must  be  supplemented  by  data  interchange  standards  such  as  Initial  Graphics  Exchange 
Specification  (IGES),  CGM,  and  the  Standard  for  the  Exchange  of  Product  Model  Data  (STEP). 

3.6.2.1  Vector  graphics  APIs.  The  Programmer's  Hierarchical  Interactive  Graphics  System 
(PHIGS)  is  a  graphics  system  and  language  allowing  programming  of  two-dimensional  and  three- 
dimensional  graphical  objects  to  be  displayed  or  plotted  on  appropriate  devices  in  interactive,  high 
performance  environments,  and  managing  hierarchical  database  structures  containing  graphics 
data.  PHIGS  is  a  device-independent  interface  between  the  application  program  and  the  graphics 
subsystem.  PHIGS  manages  graphics  objects  in  a  hierarchical  manner  so  that  a  complete  assembly 
can  be  specified  with  all  of  its  subassemblies.  The  Graphical  Kernel  System  (GKS)  is  a  graphics 
system  that  is  independent  of  the  operating  system  and  provides  basic  primitives  and  constructs 
for  drawing  two-dimensional  objects  to  be  displayed  or  plotted  on  appropriate  devices  (raster 
graphics  and  vector  graphics  devices).  The  GKS  extensions  add  three-dimensional  abilities.  The 
application  programming  interfaces  (APIs)  allow  graphics  applications  to  be  developed  on  one 
system  and  easily  moved  to  another  with  minimal  or  no  change. 

3.6.2. 1.1  Standards.  Table  3.6-3  presents  standards  for  vector  graphics  APIs. 


TABLE  3.6-3  Vector  graphics  APIs  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPCAPC 

ANSI/ISO/IEC 

ProgrammeiV  Hierarchical  Interactive  Graphics  Syitem 
(PHIGS  and  PHIGS  PLUS)  (ai  profiled  by  FIPS  PUB  153- 

-  --  -  -  1)  -  -  - 

9592-1,2.3.4:1989 
with  AMDI:  1992 

Mandated 

(Approved) 

IPC 

ISQ/IEC 

Information  Technology-Computer  Graphics-Interfacing 
(CGI)  Techniques  for  Dialogue  with  Graphic!  Devices 

9636:1991 

Mandated 

(Approved) 

[PC 

ISO/ffiC 

Graphical  Kernel  System  (GKS)  functional  description  API 
(ANSI  X3. 124:1985  as  profiled  by  FIPS  PUB  120- 1: 1991 ) 

7942:1985 

Mandated 

(Approved) 

IPC 

ISO 

GKS  for  3  Dimensions  (GKS-3D)  Functional  Description 

8805:1988 

Informational  [ 
(Approved) 

3.6.2.1.2  Alternative  specifications.  No  consortia  or  de  facto  specifications  for  vector  graphics 
are  available. 

3.6.2.1.3  Standards  deficiencies.  Some  features  are  added  to  PHIGS  implementations  to 
compensate  for  perceived  deficiencies  in  the  standard  (e.g.,  adding  the  PHIGS  Plus  Lumiere  und 
Surfaces  (PLUS)  standard).  The  is  well-established  and  well-supported  by  the  computer  industry, 
but  it  is  minimal  and  other  capabilities  are  needed. 
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3.6.2. 1.4  Portability  caveats.  Most  implementations  of  PHIGS  provide  extra  features  that  are 
not  part  of  the  PHIGS  standard  and  often  are  unnecessary.  These  features  must  be  avoided  if 
possible,  since  unique  features  limit  portability.  As  with  graphics  implementations  based  on 
PHIGS,  many  nonstandard  additions  in  the  implementation  can  impede  portability. 

3.6.2.15  Related  standards.  The  following  standards  are  related  to  vector  graphics  API 
standards: 

a.  ISO/Intemational  Electrotechnical  Commission  (IEC)  9593- 1 : 1 990:  PHIGS 
Language  Bindings  -  Part  1:  FORTRAN  (corrigendum  1:1993, 2  1994). 

b  ISO/IEC  9593-3:1990:  PHIGS  Language  Bindings  -  Part  3:  Ada  (Amd  1  1994, 
Corr  1  1993. 

c.  ISO/IEC  9593-4:1991:  PHIGS  Language  Bindings  -  Part  4:  C  (Amd  1  1994  Corr 
1  1994). 

3.6.2.1.6  Recommendations.  The  mandated  standards  are  recommended.  The  PHIGS  standards 
must  be  used  without  allowing  extra  features,  and  the  use  of  options  must  be  controlled.  The 
GKS  functionality  (and  GKS-3D's  functionality)  is  totally  subsumed  and  extended  by  PHIGS. 
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3.6.2.2  Vector  graphics  data  interchange.  (This  BSA  appears  in  part  S,  Data  Interchange,  and 
part  6,  Graphics.)  These  standards  provide  file  formats  for  the  storage,  exchange,  and 
import/export  of  raster  or  vector  graphical  drawings  and  images. 

3.6.2.2.1  Standards.  Table  3.6-4  presents  standards  for  vector  graphics  data  interchange. 


TABLE  3.6-4  Vector  graphics  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Metafile  for  Storage/Tmosfer  of  Pictorial  Description 
Information  (COM)  (aa  profiled  by  FIPS  PUB  128-1  and 
MIL-STD-2301) 

8632-1,2,3,4:1992 
(w/Amd  1&2) 

Mandated 

(Approved) 

NPC/IPC 

ANS1/ISO/IEC 

Programmers'  Hierarchical  Interactive  Graphic!  System 
(PHIGS  and  PHIGS  PLUS)  (aa  profiled  by  FIPS  PUB  153- 

u 

9592-1,2,3,4:1989 
with  AMD1: 1992 

Mandated 

(Approved) 

GPC 

NIST 

FTPS  PUB 
177:1992 

Informational 

(Approved) 

NPC 

ANSI/US  PRO 

US  PRO/IPO-lOO 
(Nov  1993) 

Informational 

(Approved) 

IPC 

ANSI/NPESA 

Prepress  Digital  Data  Exchange  -  Tag  Image  File  Format 

for  Image  Technology  (TEFF/TT) 

IT8.8 

Informational 

(Approved) 

GPC 

DOD 

Digital  Repreaentation  for  Communication  of  Product 
Data:  IGES  Application  SubaeU  and  IGES  Application 
Protocol* 

MIL-PRF-28000 

Informational 

(Approved) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL.PRF-28002 

Informational 

(Approved) 

GPC 

DOD 

MIL.PRF-28003 

Informational 

(Approved) 

GPC 

DOD 

Computer  Graphics  Metafile  (CGM)  Implementation 
Standard  for  National  Imagery  Transfer  Format  Standard 
(NITFS)  (based  on  FIPS  128) 

MIL-STD-2301A 

Informational 

(Approved) 

NPC 

ANSI/AUM 

Recommended  Practice;  File  Format  for  Storage  and 
Exchange  of  Imagea;  Bi-Level  Image  File  Formal:  Part  1 

MS53-1993 

Informational 

(Approved) 

GPC 

DOD 

Digital  Representation  for  Communication  of  Product 
Data:  IGES  Application  Subsets  and  IGES  Application 
Protocols 

MIL-D-28000A(1) 
of  12/14/92 

Informational 

(Superseded) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL-R.28002BO) 
of  9/20/1993 

Informational 

(Superseded) 

GPC 

DOD 

— 

MIL-D-28003AO) 
of  8/14/1992 

Informational 

(Superceded) 

NPC 

ANS1/ASME 

Digital  Representation  for  Communication  of  Product 
Definition  Data 

YI4.26M:!989 

Informational 

(Superseded) 

3.6.2.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 


a.  BMP  (Windows  Bitmap)  -  Proprietary. 

b.  CGI  (Computer  Graphics  Interface) 

c.  GIF  (Graphics  Interchange  Format)  (Used  by  CompuServe) 

d.  NAPLPS  (North  American  Presentation  Level  Protocol  Syntax) 

e.  PDL  (Page  Description  Language)  -  Proprietary 
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f.  TIFF  (Tagged  Image  File  Format)  -  Proprietary 

g.  VDM  (Virtual  Device  Metafile) 

h.  VDI  (Virtual  Device  Interface) 

3.6.2.23  Standards  deficiencies.  The  CGM  standards  have  limited  capabilities  for  handling  3-D 
geometries,  providing  fine  control  over  line  drawing  details,  and  using  font  resource  references 
enabling  reasonably  accurate  font  substitution  (the  latter  is  an  understatement),  and  describing 
color.  Several  addenda  and  amendments  are  being  developed.  The  addenda  would  add  a  global 
symbol  capability,  3-dimensional  geometry  extensions,  and  improved  engineering  drawing 
capabilities  (such  as  better  control  over  fine  details  of  line  drawings).  The  amendments  listed  in 
table  above  are  concerned  with  fonts  and  color.  These  CGM  changes  are  intended  to  be  upwardly 
compatible  with  existing  versions  of  the  specificadon. 

3.6. 2.2.4  Portability  caveats.  Portability  problems  for  existing  versions  of  the  CGM  standard  are 
unknown.  Potential  portability  problems  exist  for  the  CGM  addenda  and  amendments,  as  with  any 
new  version  of  a  specification  or  product,  even  though  the  standards  groups  are  developing  their 
specifications  with  upward  compatibility  in  mind. 

3.6.2.2 S  Related  standards.  The  following  standards  are  related  to  graphics  data  exchange  or 
graphics  data  exchange  standards: 

a.  ISO  928 1 :  Identification  of  Picture  Coding  Methods. 

b.  ISO  10918-1:  Digital  Compression  and  Coding  of  Continuous  Tone  Still  Images, 
Part  1 :  Requirements  and  Guidelines. 

c.  ISO  10918-2:  Digital  Compression  and  Coding  of  Continuous  Tone  Still  Images, 
Part  2:  Compliance  Testing. 

d.  ISO  CD  1 1 172:  Coding  of  Moving  Pictures  and  Associated  Audio. 

e.  ISO  SC21/WG5,  N4192:  Proposed  FTAM  Document  Type  to  Support  CGM. 

f.  ISO  SC21/WG5,  N5165:  FTAM  Constraint  Set  and  Document  Types  for  CGM. 

g.  MIL-HDBK-1300A,  NITFS 

h.  MIL-STD-2500A,  National  Imagery  Transmission  Format  (N1TF)  Version  2.0  for 
the  NITFS. 

3.6.2.2.6  Recommendations.  The  mandated  standards  are  recommended. 

The  following  wording  from  the  APP  is  recommended  for  specifying  data  interchange  standards: 
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"All  computer  graphics  metafiles  acquired  to  describe,  store,  and/or  communicate  graphical 
(pictorial)  information  in  vector  format  among  different  devices,  systems,  and  installations  should 
comply  with  the  requirements  set  forth  in  FIPS  PUB  128-1,  Computer  Graphics  Metafile 
(CGM)." 

The  use  of  CGM  is  widespread,  and  many  (most)  off-the-shelf  products  for  graphics  data 
interchange  are  compatible  with  it 

It  is  important  to  consider  the  specification  of  CGM  conformance  in  procurements  because  CGM 
is  important  to  the  integration  of  PC  applications  with  the  enterprise.  Most  PC  graphics,  word 
processing  and  desktop  publishing  programs  support  the  importing  and  exporting  of  pictures, 
bidirectionally  to  other  PC  programs  and  between  PC  and  server/minicomputer/  workstation 
applications. 
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3.6.3  Device  interfaces.  An  API  is  a  set  of  formalized  software  calls  and  routines  that  can  be 
referenced  by  an  application  program  to  access  underlying  network  services.  The  vector  graphics 
standards  mid  level  service  area  also  fall  into  this  category.  Graphical  user  interfaces  are  closely 
related  to  this  area. 

3.6.3.1  Device  interface  API.  Device  interface  API  standards  provide  the  capability  to  write 
graphics  device  drivers. 

3.63.1.1  Standards.  Table  3.6-5  presents  standards  for  device  interface  APIs. 


TABLE  3.6-5  Device  interface  API  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

NPC/TPC 

ANSl/ISO/IEC 

Interfacing  Technique*  for  Dialogue*  with  Graphical 
Device*  (CGI)  •  Functional  Specification  •  Pan  1: 
Overview,  Profile*.  and  Conformance 

9636-1:1991 

Mandated 

(Approved) 

NPC/IPC 

ANSI/ISO/IRC 

'■  -  ‘ifneb?  Technique*  for  Dialogue*  with  Graphical 
*-■ .  '"ima!  Specification  -  Part  2:  Control 

9636-2:1991 

Mandated 

(Approved) 

NPC71PC 

bvefosif  ....  iv.f  loftte*  with  Graphical 

I*-. vice* (CGI)  -  PtiiKiMii-tj t,viO  Part  3:  Output 

9636-3:1991 

Mandated 

(Approved) 

NPC/IPC 

ANSl/ISO/IEC 

9636-4:1991 

Mandated 

(Approved) 

m 

ANSl/ISO/IEC 

Interfacing  Technique*  for  Didogue*  with  Graphical 
Device*  (CGI)  •  Functional  Specification  -  Part  5:  Input 
and  Echoing 

9636-5:1991 

Mandated 

(Approved) 

NPC/IPC 

ANSl/ISO/IEC 

Interfacing  Technique*  for  Dialogue*  with  Graphical 
Device*  (CGI)  •  Functional  Specification  -  Part  6:  Raster 

9636-6:1991 

Mandated 

(Approved) 

[PC 

ISO/IEC 

UiUpHiiSl 

9637-1:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

9637-2:1994 

Informational 

(Approved) 

3.6.3.1.2  Alternative  specifications.  Numerous  unique  proprietary  APIs  are  available  for  specific 
vendor  devices. 

3.6.3.1.3  Standards  deficiencies.  A  single  standard  and  many  implemt!rw«><>*!>-  <■■>'  a  device 
interface  API  may  add  features  desirable  in  future  standards. 

3.6.3. 1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.6.3. 1.5  Related  standards.  The  following  standards  are  related  to  device  interface  API 
standards: 


a.  ISO/IEC  9638-1:  CGI  Language  Bindings  -  Part  1 

b.  ISO/IEC  9638-2:  CGI  Language  Bindings  -  Part  2 
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c.  ISO/IEC  DIS  9638-3: 1993  CGI  Language  Bindings  -  Part  3:  Ada 
3.6. 3. 1.6  Recommendations.  CGI  is  the  recommended  device  interface  API  for  graphics. 
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3.63 2  Image  processing  API.  Image  processing  API  standards  provide  basic  facilities  and 
interfaces  f u  imaging  applications  at  the  machine  level. 

3.63.2.1  Standards.  Table  3.6-6  presents  standards  for  image  processing  APIs. 


TABLE  3.6-6  Image  processing  API  standards 


Standard 

Type 

Sponsor 

Standard 

Stanc  -I 
Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  FunctiooaJ 
Specification:  Part  1 :  Common  Architecture 

120874:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  Functional 
Specification:  Part  2:  Programmer*  Imaging  Kernel  System 
API 

12087-2:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Image  Procr-L^  and  Interchange  (IPI)  Functional 
Specific*  on,  Part  3:  Image  Interchange  Facility  (IIF) 

12087-3:1995 

Infounational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  API  Language 
Bindings  Part  4:  C 

12088-4:1995 

Infounational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  Functional 
Specification,  Part  3:  Image  Interchange  Facility  (IIF) 
Amendment  1 :  Type  Definition,  Scoping,  and  Logical 
View*  for  Image  Interchange  Facility 

12087-3  DAM 
1:1994 

Informational 

(Draft) 

IPC 

ISO/IEC 

Encoding  for  the  Image  Processing  and  Interchange 
Standard  (IPI)  -  Encoding  for  the  Image  Interchange 
Facility  (IIF) 

12089:1994 

Informational 

(Draft) 

GPC 

NIST 

Image  Processing  and  Interchange  (IPI)  Functional 
Specification:  Programmer*  Imaging  Kernel  System  API 

Image 

Processing  and 
Interchange  (IPI) 

Informational 

(Formative) 

3.63.2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.3.23  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.63.2.4  Portability  caveats.  Deficiencies  in  the  existing  IPI  standards  are  unknown. 

3.6.3.23  Related  standards.  The  language  interface  bindings  for  IPI  (ISO  12088)  are  related. 

3.63.2.6  Recommendations.  Use  the  current  version  of  IPI,  including  the  most  current  drafts  of 
the  unfinished  parts,  and  implement  a  transition  to  the  final  standard. 
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3.6.4  Geospatial  (MC&G).  Standards  for  geospatial  (Mapping,  Charting,  and  Geodesy) 
products  such  as  maps,  charts,  and  computer  displays  include  graphics  symbols  and  formats  for 
informadon  storage  and  processing. 


3.6.4.1  Symbology  graphics.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  6, 
Graphics.)  These  are  standards  for  the  symbology  to  be  used  in  geospadal  applications  such  as 
hardcopy  mapping  products  and  computer-generated  displays.  DoD  standards  provide  definitions 
for  the  representation  of  military  and  intelligence  information. 

3.6.4.1.1  Standards.  Table  3.6-7  presents  standards  for  symbology  graphics. 


TABLE  3.6-7  Symbology  graphics  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DC  I)  (US  Army) 

Human  Factor*  Engineering  Design  Criteria  for  Helicopter 
Cockpit  Electro-Optical  Duplay  Symbology 

MIL-STD-1295A 
of  6/26/19*4 

Adopted 

(Approved) 

GPC 

DOu  (USAF) 

Aircraft  Diqday  Symbology 

MIL-STD-I787B 
of  6/93 

Adopted 

(Approved) 

GPC 

DOD  (NIMA) 

Mapping,  Charting  and  Geodety  (MC&G)  Symbology  for 
Graphic  Product! 

MTL-STD-2402  of 
2/95 

Adopted 

(Approved) 

GPC 

DOD  (D1SA) 

Common  Waifighting  Symbology,  Version  1 

MEL-STD-2525 

Adopted 

(Approved) 

GPC 

WMO 

HUgBgHHHH 

WMO  Document 
#49  of  1988 

Adopted 

(Approved) 

GPC 

DOD 

Military  Symbol! 

Q-STAG  509  of 
3/5/1979 

Informational 

(Approved) 

NPC 

ANS1/SAE 

Human  Interface  Deiign  Methodology  for  Integrated 
Diiplay  Symbology 

ARP  4 155  (1990) 

Infoimational 

(Approved) 

GPC 

DOD  (US  Amy) 

Symboli  for  Army  Air  Defenae  System  Displays 

MIL-STD-1477B 
of  2/1/1993 

Informational 

(Approved) 

GPC 

DOD  (DISA) 

Common  Warfighting  Symbology,  Version  2 

MD.-STD-2525A 

Informational 

(Approved) 

GPC 

DOD  (US  Army) 

Army  Field  Manual  (FM):  Operational  Terms  and  Symbols 

IKS 

Informational 

(Approved) 

NPC 

ANSI/ISA 

Instrumentation  Symbols  and  Identification 

S5. 1-1984  (R1992) 

Informational 

(Approved) 

NPC 

ANSI/ISA 

Graphic  Symbol*  for  Process  Displays 

S5.5-1985 

Informational 

(Approved) 

IPC 

NATO 

NATO  Experimental  Tactics  and  Amplifying  Tactical 
Instructions  -  AXP-5(B)  (Navy/Air) 

STAN  AG  1125 

Informational 

(Approved) 

IPC 

NATO 

Military  Symbols  for  Land  Based  Systems  (APP-6,  Ed  3) 

STANAG  2019(1) 
of  M/26/1990 

Informational 

(Approved) 

IPC 

NATO 

Electronically  and/or  Optically  Generated  Aircraft  Displays 
for  Fixed  Wing  Aircraft 

STANAG  3648  of 
6/29/1990 

Informational 

(Approved) 

IPC 

NATO 

Symbols  on  Land  Maps,  Aeronautical  Charts  and  Special 
Naval  (harts 

STANAG  3675 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

Symbolt  for  Use  on  Map  of  Training  Aren  for  Land 
Force* 

STANAG  3833 

Informational 

(Annoyed) 

(PC 

CJCS 

Joint  Symbol!  and  Graphic! 

Joint  Pub  1-06 

Informational 

(Drift) 

GPC 

DOD  (US  Aimy) 

Army  field  Manual  (FM):  Operational  Terau  and  Symbols 

FM  101  -5-1 A 
SMIGS 

Informational 

(Drift) 

GPC 

DOD  (NIMA) 

Vector  Product  Format  Symbology 

MIL- PRF-8 9045 

Informational 

(Drift) 

GPC 

DOD  (ASPO) 

Symbol  Automation 

MIL-STD- 25 26 

Informational 

(Drift) 

GPC 

DIA 

Standard  Military  Graphic!  Symbol!  (SMIGS) 

DIAM  65-xx 

Informational 

(Drift) 

IPC 

NATO 

Duplay  Symbology  and  Colon  for  NATO  Maritime  Unitt 

STANAG  4420 

Informational 

(Formative) 

3.6.4.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.6.4.  IJ  Standards  deficiencies.  Draft  MIL-STD-2525A  does  not  currently  contain  weather, 
geospatial  (mapping/charting),  cockpit  display,  and  engineering  design  symbology.  Therefore 
NIMA  MIL-STD-2402, 2412  should  be  used  for  geospatial  symbology  until  such  time  as  a 
decision  is  made  to  modify  MIL-STD-2525A  to  accomodate  these  symbols. 

3.6.4. 1.4  Portability  caveats.  Portability  will  be  reduced  if  a  Geographic  Information  System 
(GIS)  does  not  allow  users  to  associate  their  cartographic  data  independently  with  relational 
database  management  systems  based  on  Structured  Query  Language  (SQL).  Only  government 
standards  are  available.  Most  commercial  products  will  not  comply  with  these  standards. 

3.6.4.1.5  Related  standards.  The  following  standards  are  related  to  symbology  graphics  or 
symbology  graphics  standards: 

a.  ISO  6937:  Supplementary  Characters  (for  accents  to  the  text) 

b.  ISO  9292:  Picture  Coding 

c.  Autometric,  Inc.,  Lakewood,  CO:  MOSS 

d.  Map  graphics  standards. 

3.6.4.1.6  Recommendations.  The  adopted  symbology  standards  are  recommended,  as  applicable; 
MIL-STD  2525  is  the  recommended  standard  for  warrior  symbology. 
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3.6.4J  Geospatial  data  interchange.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part 
6,  Graphics.)  These  standards  provide  formats  and  facilities  for  machine-readable  graphics-based 
mapping,  charting,  and  geodesy  data. 

3.6.4.2.I  Standards.  Table  3.6-8  presents  standards  for  geospatial  data  interchange. 


TABLE  3.6-8  Geospatial  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD  (NIMA) 

World  Geodetic  System  (WGS  84) 

MIL- STD- 2401  of 
21  Maid)  1994 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Raster  Product  Format  (RPF) 

MIL-STD- 

2411:1994 

Mandated 

(Approved) 

GPC 

DOD  (NIMA) 

Interface  Standard  for  Vector  Product  Format  (VPF) 

MIL-STD-2407 

Mandated 

(Approved) 

IPC 

NATO 

STANAG  7074 

Informational 

(Approved) 

GPC 

NIST 

Spatial  Data  Transfer  Standard  (SDTS) 

HUH 

Informational 

(Approved) 

IPC 

NATO 

Digital  Terrain  Elevation  Data,  (DIED) 

STANAG  3809 

Informational 

(Approved) 

GPC 

NIST 

Representation  of  Geographic  Point  Location*  for 
informadoo  Interchange  (adopts  ANSI  X3.61-1986) 

FIPS  PUB  70- 
1:1986 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB 
103:1983 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

NIMA  GGI&S  Lilt  of  Product*  and  Service* 

NIMAL  805-1  A, 
Jan  1997 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Arc  Digitized  Raster  Graphics  Worldwide  Map  Images  on 
CD-ROM,  1:5,000  through  1:2,000,000 

M1L-A-89007  of 
2/22/1990 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

DIED  (Machine  readable  terrain/elevation  data  for  the 
U.S.,  the  former  USSR,  Europe,  Central  Asia,  Mideast, 
Parts  of  Southern  Alia,  Northern  Canada,  3-Arc-Sec) 

MIL- D- 89000  of 
2/26/90  M3L-D- 
89001  of  2/26/90 
MIL-D-89020  of 
5/28/93 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

MIL -D- 8 9009  of 
4/13/92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Digital  Cities  Data  Base  (DCDB) 

MIL-D-8901 1  of 
7/2/90 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Firefutder  Elevation  Data  (FED) 

MIL-D-8901 8  of 
10/1/92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Digital  Landman  Blanking  (DLMB) 

MIL-D-89021  of 
6/15/91 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Interim  Terrain  Dala/Planiting  Interim  Terrain  Data 
(ITD/PITD) 

MIL-1-89014  of 

1 1/30/90 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

MIL-V-89300(l)of 

1 1/30/92 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD(NlMA) 

Worid  Vector  Sho  rehoe  (dso  wing  Worldwide  Coastlines 
and  International  Boundaries,  1:250,000  scale) 

MIL- W- 8901 2(2) 
of  11/30/92 

Informational 

(Approved) 

GPC 

DOD  (NIMA) 

Worid  Magnetic  Model  (WMM) 

MIL-W-89500  of 
6/18/93 

Informational 

(Approved) 

GPC 

DARPA 

SIMNET  Geographic  Data  Model  and  Database 
Interchange  Specification 

BBN  DARPA 
Report  7108  July 
1989 

Informational 

(Approved) 

OPC 

NODC 

Worid  wide  Coverage  for  5  Mini  Grid  maps: 
BathymetricjElevation  Data 

ETOP0  5 

Informational 

(Approved) 

OPC 

USGS 

LANDS  AT:  Worldwide  Coverage  for  1:1,000,000  Scale 
Maps:  Feature/Terrain  Data 

LANDSAT 

Informational 

(Approved) 

IPC 

NATO 

Scope  and  Presentation  of  Military  Geographic  Information 
and  Documentation 

STANAG  2251 

Informational 

(Approved) 

rpc 

NATO 

Roads  and  Road  Structures 

STAN  AG  2253 

Informational 

(Approved) 

IPC 

NATO 

MGD-Ports 

STANAG  2255 

Informational 

(Approved) 

IPC 

NATO 

Indexes  to  series  of  Land  Maps  and  Aeronautical  Charts 
and  Indexes  to  Military  Geographic  Information  and 
Documentation  (MG ID) 

STANAG  3672 

Informational 

(Approved) 

IPC 

NATO 

STANAG  3985 

Informational 

(Approved) 

IPC 

NATO 

Digital  Data  Hie  Transmittal  Form  for  Geographic 
Information 

STANAG  3986 

Informational 

(Approved) 

OPC 

USOS 

Specification  for  Representation  of  Geographic  Point 
Locations  for  Information  Interchange  (adopts  ANSI 
X3.61-1986) 

USGS  Circular 
87&-B  of  1983 

Informational 

(Approved) 

OPC 

USOS 

Digital  Elevation  Models 

USGS  Circular 
895-B  of  1983 

Informational 

(Approved) 

GPC 

USOS 

Digital  Line  Graphs  from  1 :24,0OO  Scale  Maps 

USGS  Circular 
895-C  of  1983 

Informational 

(Approved) 

GPC 

USOS 

Digital  Line  Graphs  from  1 :2, 000, 000  Scale  Maps 

USGS  Circular 
895-D  of  1983 

Informational 

(Approved) 

OPC 

USGS 

Land  Use  and  Land  Cover  Digital  Data 

USGS  Circular 
895-E  of  1983 

Informational 

(Approved) 

GPC 

USGS 

Geographic  Names  Information  System 

USGS  Circular 
895-F  of  1983 

Informational 

(Approved) 

OPC 

CIA 

Worid  Data  Bank  11:  Worldwide  Coverage  for  1 :2, 000.000 
Scale  Maps  (Lines  of  Communication,  Coastlines, 
Waterways,  Intemaiional/Political  Boundaries) 

Worid  Data  Bank  II 

Informational 

(Approved) 

GPC 

DOD  (USAF) 

Arc  Digital  Raster  Imagery  (ADRI)  Format 

M1L-STD-2406 

Informational 
(Final)  fl 

GPC 

DOD  (NIMA) 

Standard  Linear  Format  (SLF)  Digital  Cartographic 
Feature 

MILHDBK-854 

Informational  B 

(Final)  j 

GPC 

DOD  (AFMC) 

Registered  Data  Values  for  Raster/Gridded  Product  Format 

MIL-HDBK-856 

Informational  1 

(Final)  | 

GPC 

DOD  (NIMA) 

Text  Product  Form  (TPF) 

MIL-STD-2400 

Informational  B 

(Final)  | 

OPC 

DOD  (NIMA) 

Mapping  Charting  and  Geodesy  Symbology  Graphics 

Ml  L-STD- 600002 

Informational  | 
(Draft)  j 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

Header  Record  Format  for  Exchange  of  Digits!  Geographic 
Information 

STANAG  39M 

Informations! 

(Draft) 

IPC 

NATO 

DifiUl  Geographic  Infomutioc  DaU  Sett  Series 
Numbering 

STAN  AG  7070 

Informations! 

(Draft) 

GPC 

DOD  (NIMA) 

DFAD  (Machine-readable  feature  data  of  the  U.S.,  Europe, 
the  former  Western  USSR,  Limited  Arees  of  Fer  Eest  and 
Western  Asia,  1:250.000  scale) 

MIL-D-890Q5 

Informations! 

(Draft) 

GPC 

DOD  (NIMA) 

Tactiul  Terrain  Data:  Dlgiui  Dstsbsse  for  1 :50.000  Scde 

Msps 

TBD-Tactical 

Tensin  Data: 
Digits!  Database 

for  1:50,000  Scale 

Maps 

Informations! 

(Foimative) 

3.6.4.2.2  Alternative  specifications.  Many  existing  proprietary  map  graphics  applications  vary  in 
complexity  to  meet  users'  needs.  These  applications  serve  as  the  cornerstone  of  the  mapping, 
charting,  and  geodesy  areas  requiring  further  investigation  for  standardization  consideration. 

3.6.4.223  Standards  deficiencies.  Many  of  the  standards  listed  in  the  table  accompanying  this 
section  are  old.  They  do  not  accommodate  new  sophisticated  computerized  techniques,  and 
probably  will  be  replaced  in  the  next  several  years.  The  standards  available  pertain  almost 
exclusively  to  the  data  rather  than  the  functionality  of  an  application. 

3.6.4.2.4  Portability  caveats.  Portability  will  be  reduced  if  a  GIS  does  not  allow  users  to 
associate  their  cartographic  data  independently  with  relational  database  management  systems 
based  on  SQL. 

The  use  of  different  file  formats  by  a  GIS  reduces  portability.  However,  in  the  production  world 
several  file  formats  specified  by  vendors  are  used  so  widely  that  they  are  considered  neutral  file 
formats  (e.g..  Intergraph's  Standard  Interchange  Format  (SIF),  Autodesk's  Drawing  Exchange 
Format  (DXF),  and  MOSS). 

Traditionally,  standards  governing  exchanges  among  field  systems  have  been  the  responsibility  of 
the  military  system  development  organization.  This  leads  to  substantial  interoperability  problems, 
particularly  international.  To  maximize  interoperability,  Digital  Geographic  Information  Exchange 
Standard  (DIGEST)  and  other  map  producing  data  should  be  exchanged  between  map-producing 
agencies,  such  as  the  National  Imagery  and  Mapping  Agency  (NIMA)  and  not  between 
operational  units,  and  the  systems  development  organizations  should  use  the  standards  set  by  such 
agencies  as  the  NIMA. 

Portability  difficulties  may  exist  between  the  Vector  Product  Format  (VPF)  and  the  Spatial 
Transfer  Specification  (SDTS). 

Portability  can  be  especially  difficult  in  an  area  where  so  many  standards  exist. 
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3.6.4 .2.5  Related  standards.  The  following  standards  are  related  to  map  graphics  exchange  or 
exchange  standards: 

a.  ISO  646: 7-bit  Coded  Character  Set  for  Information  Interchange 

b.  ISO  1001:  File  Structure  and  Labeling  of  Magnetic  Tapes  for  Information 
Interchange 

c.  ISO  2375:  Non-Latin  Alphabets 

d.  ISO  6937:  Supplementary  Characters  (for  accents  to  the  text) 

e.  ISO  821 1 : 1985  Specification  for  a  Data  Descriptive  File  for  Information  Exchange 

f.  ISO  8824/8825:  ASN.l 

g.  ISO  9292:  Picture  Coding 

b.  ISO  9660: 1988  Volume  and  File  Structure  of  CD  ROM  for  Information  Exchange 

i.  ANSI/ASME  Y14.26M-1989:  IGES  (Neutral  file  format) 

j.  Intergraph  Corporation,  Huntsville,  AL:  SIF 

k.  Autodesk,  Inc.,  Sausalito,  CA:  DXF 

L  Autometric,  Inc.,  Lakewood,  CO:  MOSS 

m.  The  various  data  compression  standards  listed  earlier  in  the  section  on  data 
compression 

3.6.4.2.6  Recommendations.  GIS  specifications  in  a  procurement  should  require  SQL 
compatibility  so  that  cartographic  data  can  be  associated  independently  with  relational  database 
management  systems  based  on  SQL.  In  each  case,  consideration  of  the  scale  of  data  and 
geographic  region  needed  will  be  a  primary  determinant  in  selection.  The  standards  in  the  table 
above  labeled  mandated  are  recommended.  The  VPF  is  preferred. 

If  a  packaged  GIS  is  to  be  purchased,  if  possible,  it  should  be  standardized  around  a  single  GIS 
file  format.  If  a  GIS  is  to  be  used  on  workstations  and  PCs,  this  may  not  be  possible.  Then  the 
agency's  focus  will  have  to  be  on  the  use  of  interoperability  protocols  and  designing  applications 
for  portability.  GIS  specifications  should  require  SQL  compatibility  so  that  cartographic  data  can 
be  associated  independently  with  relational  database  management  systems  based  on  SQL. 
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3.6.5  Editors.  An  editor  is  a  software  program  used  to  modify  programs  or  files  while  they  are 
being  prepared,  or  after  they  are  complete.  A  textual  editor  is  a  very  rudimentary  word  processing 
program.  The  following  editors  provide  the  services  for  creating  and  editing  nontextual  data. 

3.6.5. 1  Graphics  editor.  A  graphics  editor  provides  an  interactive  editor  to  create,  edit,  and 
compose  drawings,  symbols,  and  maps. 

3.63.1.1  Standards.  Table  3.6-9  presents  standards  for  graphics  editors. 


TABLE  3.6-9  Graphics  editor  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ii| 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.6.5.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.5.13  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.5.1.4  Portability  caveats.  This  is  a  high  portability  risk  area,  because  no  standards  exist 
3.6.5.13  Related  standards.  The  following  standards  are  related  to  graphics  editor  standards: 


a. 

ISO  9592:1989  PHIGS. 

b. 

ISO  7942: 1985  GKS. 

c. 

ISO  109 18- 1.1994  JPEG. 

d. 

ISO  1 1 172:  MPEG. 

c. 

ANSI  X3H3.8:  PIK. 

f. 

ISO  10918-2. 

3.6.5. 1.6  Recommendations.  Carefully  match  specific  requirements  for  a  graphics  editor  to  the 
capabilities  offered  by  any  appropriate  implementation. 
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3.6.5.2  Image  processor  editor.  Image  processing  editors  analyze  a  picture  using  techniques  that 
can  identify  shades,  colors,  and  relationships  not  perceptible  by  the  human  eye.  These  editors  also 
perform  image  improvement,  such  as  refuting  a  picture  in  a  paint  program  that  has  been  scanned 
or  entered  from  a  video  source. 

3.6.5.2.1  Standards.  Table  3.6-10  presents  standards  for  image  processor  editors, 


TABLE  3.6-10  Image  processor  editor  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

None 

N.A. 

Infomutioctl 

(N.A.) 

3.6.S2.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.S.2J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.5.2.4  Portability  caveats.  This  is  a  higli  portability  risk  area,  because  no  standards  exist 

3.6.5.2.5  Related  standards.  The  following  standards  are  related  to  image  processor  editor 
standards: 


a. 

ISO  9592:1989  PHIGS 

b. 

ISO  7942:1985  GKS 

c. 

ISO  10918-1:1994  JPEG 

d. 

ISO  11172:  MPEG 

e. 

ANSI  X3H3.8:  PIK 

f. 

ISO  10918-2 

3.6.5.2.6  Recommendations.  There  are  no  standards  to  recommend.  It  is  suggested  that 
requirements  be  specified  to  anticipate  future  needs. 
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3.6.5  3  Videoprocessor  editor.  Videoprocessing  editors  provide  an  interactive  editor  to  capture, 
scan,  create,  and  edit  live,  full-motion  video. 

3.6.5. 3.1  Standards.  Table  3.6-1 1  presents  standards  for  videoprocessor  editors. 


TABLE  3.6-11  Videoprocessor  editor  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.6.5 .3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.5.33  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.53.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.6.5.33  Related  standards.  The  following  standards  are  related  to  videoprocessor  editor 
standards: 


a. 

ISO  9592:1989  PHIGS 

b. 

ISO  7942:1985  GKS 

c. 

ISO  10918-1:1994  JPEG 

d. 

ISO  11172:  MPEG 

e. 

ANSI  X3H3.8:  PIK 

f. 

ISO  10918-2:JPEG 

3.6.53.6  Recommendations.  See  the  Image  Processor  Editor  BSA. 
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3.6.6  Graphics  search  and  sort  Graphics  search  and  sort  standards  provide  capability  and 
standardized  interface  to  search  for  and  access  graphical  objects  based  on  file  attributes. 

3.6.6.1  Graphics  search.  Graphics  search  standards  provide  the  capability  and  standardized 
interface  to  search  for  and  access  graphical  objects  based  on  file  attributes. 

3.6.6.1.1  Standards.  Table  3.6-12  presents  standards  for  graphics  searches. 


TABLE  3.6-12  Graphics  search  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.6.6.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.C.6.U  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.6.1.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.6.6. 1.5  Related  standards.  The  following  standards  are  related  to  graphics  search  or  graphics 
search  standards: 


a. 

ISO  9592:1989  PHIGS 

b. 

ISO  7942: 1985  GKS 

c. 

ISO  10918-1:1994  JPEG 

d. 

MIL-STD-188-198:  JPEG 

e. 

ISO  11 172:  MPEG 

f. 

ANSI  X3H3.8:  PIK 

g- 

ISO  10918-2  JPEG 

3.6.6. 1.6  Recommendations.  Without  standards,  specifications  should  reflect  current  needs  and 
anticipate  future  changes. 


April  7,  1997 


3.6-24 


Version  3. 1 


Information  Technology  Standards  Guidance 


Graphics  Services 


3.6.6 2  Image  query  and  search.  Image  query  and  search  standards  provide  the  capability  and 
standardized  interface  to  search  for  and  access  image  data  based  on  file  attributes. 

3.6.6.2.1  Standards.  Table  3.6-13  presents  standards  for  image  queries  and  searches. 


TABLE  3.6-13  Image  query  and  search  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

N/A 

N.A. 

None 

N.A. 

Informational 

(N.A.) 

3.6. 6.2. 2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.6.2  .3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.6.2.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.6.6.2.5  Related  standards.  The  following  standards  are  related  to  image  query  and  search 
standards: 


a. 

ISO  9592:1 989  PHIGS 

b. 

ISO  7942:1985  GKS 

c. 

ISO  10918-1:1994  JPEG 

d. 

ISO  1 1 172:  MPEG 

e. 

ANSI  X3H3.8:  PIK 

f. 

ISO  10918-2 

3.6.6.2.6  Recommendations.  No  standard  is  available  to  recommend.  Only  a  proprietary  solution 
that  best  fits  the  requirements  of  the  system  or  a  custom-developed  implementation  is  possible. 
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3.6.63  Graphical  object  sorting.  Graphical  object  sorting  standards  provide  the  capability  and 
standardized  interface  to  arrange  graphical  objects  and  information  in  a  specified  order. 

3.6.63.1  Standards.  Table  3.6- 14  presents  standards  for  graphical  object  sorting. 


TABLE  3.6-14  Graphical  object  sorting  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

N/A 

N.A. 

Nooe 

N.A. 

InfoimationaJ 

(N.A.) 

3.6.63.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.6.6.33  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.6.63.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.6.6.33  Related  standards.  The  following  standards  are  related  to  graphical  object  sorting 
standards: 


a. 

ISO  9592: 1989  PHIGS. 

b. 

ISO  7942:1985  GKS. 

c. 

ISO  10918-1:1994  JPEG. 

d. 

ISO  11 172:  MPEG. 

e. 

ANSI  X3H3.8:  PIK. 

f. 

ISO  10918-2 

3.6.63.6  Recommendations.  No  standards  are  available  to  recommend.  See  the  Image  query  and 
search  BSA. 
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3.6.7  Graphics  security.  Graphics  security  services  include  graphics  security  labeling. 

3.6.7.1  Graphics  security  labeling.  (This  BSA  appears  in  part  6  and  part  10.)  Graphics  security 
labeling  provides  a  security  service  for  ensuring  that  graphical  data  includes  labeling  information 
in  support  of  mandatory  access  control  security  services,  marking  security  services,  handling 
security  services,  aggregation  security  services,  sanitization  security  services,  and  release  security 
services.  Security  labeling  services  produce  and  maintain  the  integrity  of  the  security  label  and  its 
binding  to  the  data  with  which  it  is  associated. 

3.6.7.1.1  Standards.  Table  3.6-15  presents  standards  for  graphics  security  labeling. 


TABLE  3,6- IS  Graphics  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GFC 

DOD 

The  DOD  Trailed  Computer  Syatema  Evaluation  Criteria 

DOD  5200.23- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

CMW :  -  ‘eling  Encoding  Formal 

DDS-2600-6216- 

91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  User  Interface 
Guideline! ,  Re  virion  1 

DDS-26004243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Wortitetion  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

3.6.7.1.2  Alternative  specifications.  There  are  no  other  specifications. 

3.6.7. Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.6.7.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.6.7. 1.5  Related  standards.  Graphics  security  labeling  should  be  compatible  with  MIL-STD- 
2045-48501,  Common  Security  Label,  for  any  system  with  a  communications  interface. 

DOD  5200.1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information. 

3.6.7.1.6  Recommendations.  The  mandated  standard  is  recommended.  Graphics  security 
labeling  should  be  based  on  the  operating  system  security  label  standards.  Graphics  security 
labeling  should  employ  binding  of  strength  equal  to  or  greater  than  that  of  the  operating  system. 
Compatible  security  labeling  standards  include  the  ability  to  perform  a  one-for-one  mapping  or 
translation  between  security  labeling  standards. 
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3.7  Communications  and  network  services.  Provision  of  communications  and  network  services 
for  DOD  users  requires  a  set  of  information  transfer  standards  encompassing  all  end  systems  and 
the  subnetworks  that  interconnect  them.  Most  end  systems  for  data  use  the  TCP/IP  suite  of 
internet  protocols,  which  support  internetworking  operations  over  differing  subnetwork 
technologies.  Other  end  systems  support  voice,  fax,  messaging,  and  video  services.  This  part  of 
the  ITSG  identifies  the  base  standards  which  support  these  communicating  end  systems,  as  well  as 
the  subnetwork  technologies,  the  transmission  systems,  and  the  interworking  protocols  used  to 
interconnect  those  end  systems. 

3.7.1  Base  standards.  Base  standards  supporting  each  of  the  BSAs  are  listed  u\  tables  provided 
in  3.7.2  to  3.7.9.  The  tables  provide  the  standards  organization  numbers,  titles,  standards  types, 
and  base  standards  categories.  Some  of  the  most  used  standards  types  will  appear  in  abbreviated 
form  throughout  this  part.  These  types  and  their  abbreviations  are:  Corporate  Private  Non- 
Consensus  (CPN-C),  Consortia  Public  Consensus  (CPC),  Government  Public  Consensus  (GPC), 
International  Public  Consensus  (IPC),  and  National  Public  Consensus  (NPC).  The  ITSG,  part  1, 
provides  more  information  on  these  standards  types.  Some  base  standards  are  referenced  more 
than  once.  For  example,  a  base  standard  applicable  to  the  user-to-network  interfaces  (UNI)  may 
be  referenced  once  as  it  applies  to  the  end-system  side  of  the  UNI  and  again  as  it  applies  to  the 
network  side  of  the  UNI. 

3.7.1.1  Base  standards  categories.  Base  standards  supporting  each  of  the  BSAs  are  categorized 
as  mandated,  adopted,  legacy,  emerging,  and  informational.  These  categories  are  in  addition  to 
the  life-cycle  status  information  usually  presented.  Each  of  these  new  categories  is  described  in 

3.7.1. 1.1  to  3.7.1. 1.5. 


3.7.1. 1.1  Mandated  standard.  The  DOD  status  "Mandated"  is  used  for  those  standards 
mandated  by  the  JTA.  A  standard  is  mandatory  in  the  sense  that  IF  a  service/interface  is  going  to 
be  implemented,  it  shall  be  implemented  in  accordance  with  the  mandated  standard.  Although 
these  standards  are  mandated  for  C41  only,  they  should  be  treated  as  recommended  standards  for 
non-C4I  applications. 

3.7.1. 1.2  Adopted  standard.  The  DOD  status  "Adopted"  is  used  to  mean  that  the  standard  in 
the  ITSG  is  approved  by  DOD  for  use  in  satisfying  a  function  of  the  BSA  where  there  exists  no 
JTA  mandated  standard  where  joint  interoper abi lity  is  impacted.  Adopted  standards  may  be 
implemented  but  shall  not  be  used  in  lieu  of  a  mandated  standard.  Adopted  standards  also  appear 
in  the  top  rows  of  the  standards  tables  in  the  ITSG  and  are  bordered  with  heavy  black  lines. 

3.7.1. 1.3  Legacy  standard.  A  "Legacy"  standard  is  a  standard  necessary  to  achieve  or  maintain 
interoperability  with  legacy  systems.  Legacy  systems  are  systems  that  are  in  current  use.  Legacy 
standards  are  not  recommended  for  future  procurements.  Legacy  standards  may  be  supported 
until  the  legacy  system  is  no  longer  being  maintained.  Examples  of  legacy  standards  are  X.25 
packet  switching  standards  and  TRI-TAC/Mobile  Subscriber  Equipment  (MSE)  System  standards 
such  as  MIL-STD-188-256. 
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3.7.1.1.4  Emerging  standard.  According  to  the  JTA,  a  DOD  "Emerging"  status  denotes  a 
candidate  standard  to  be  added  as,  or  to  replace,  a  mandated  standard.  This  includes  standards 
required  to  capitalize  on  new  technologies.  These  candidates  will  help  the  program  manager 
determine  those  areas  that  are  likely  to  ch  .m«t  in  the  near  term  (within  three  years)  and  suggest 
those  areas  in  which  "upgradability”  should  be  a  concern.  The  expectation  is  that  emerging 
standards  will  be  elevated  to  mandated  status  in  the  JTA  when  implementations  of  the  standards 
mature.  Emerging  standards  may  be  implemented  but  shall  not  be  used  in  lieu  of  a  mandated 
standard. 

3.7.1.1.5  Informational  standard.  Informational  standards  include  those  remaining  rtr.'dards 
that  fall  outside  the  official  DOD  status  of  "mandated",  "adopted",  "emerging",  and  "legacy". 

3.7.1.2  LAB  standards.  A  number  of  standards  mandated  in  this  part  are  published  by  the 
Internet  Architecture  Board  (IAB),  which  is  responsible  for  the  Transmission  Control 
Protocol/Intemet  Protocol  (TCP/IP)  suite  and  which  documents  these  standards.  A  list  of  IAB 
standards  cited  in  this  part  of  the  ITSO  and  the  Request  For  Comments  (RFCs)  that  make  up 
these  standards  is  given  in  Table  3.7-1.  IAB  standards  can  be  obtained  via  electronic  mail  from 
FTP.IS1.EDC  by  using  the  RFC-INFO  service,  Address  the  request  to  "rfc-info@isi.edu"  with  a 
message  body  of: 

Retrieve:  STD 

Doc-ID:  STDnnnn  (where  nnnn  refers  to  the  number  of  the  STD,  e.g.,  STD0002  for 
IAB  STD  2) 

IAB  standards,  and  other  Internet  documentation,  can  also  be  obtained  via  a  WWW  browser  from 
URL  http://ds.intemic.net/ds/dspgOintdoc.html, 


TABLE  3.7-1  IAB  Standards  and  RFCs 


IAB  STANDARD 

RFC  NUMBER 

IAB 

STD 

NAME 

3 

Host  Requirements 

1122, 1123 

5 

Internet  Protocol 

0791,0950,  0919, 
0922,0792,  1112 

6 

User  Datagram  Protocol 

0768 

7 

Transmission  Control  Protocol 

0793 

8 

TELNET  Protocol 

0854, 0855 

9 

File  Transport  Protocol 

0959 

13 

Domain  Name  System 

1034, 1035 

15 

Simple  Network  Management  Protocol 

1157 
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|  LAB  STANDARD 

RFC  NUMBER 

LAB 

STD 

NAME 

16 

Structure  of  Management  Information 

1155, 1212 

17 

Management  Information  Base 

1213 

33 

Trivial  Hie  Transfer  Protocol 

1350 

35 

ISO  Transport  Service  on  Top  of  the  TCP 

1006 

37 

An  Ethernet  Address  Resolution  Protocol 

0826 

38 

A  Reverse  Address  Resolution  Protocol 

0903 

41 

Standard  for  the  Transmission  of  IP  Datagrams  over  Ethernet 
Networks 

0894 

43 

Standard  for  the  Transmission  of  IP  Datagrams  over  IEEE 

802  Networks 

1042 

51 

The  Point-to-Point  Protocol  (PPP) 

1661,  1662 
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3.7.2  Communications  for  end  systems.  End  systems  may  be  host  computers  [data  terminal 
equipment  (DTE)],  video  teleconferencing  (VTC)  terminals,  facsimile  terminals,  secondary 
imagery  terminals,  or  telephone  terminals. 

3.7 2.1  Host  application  support  Hosts  are  end-user  computer  systems  that  connect  to  a 
network.  They  perform  numerous  functions  corresponding  to  all  layers  of  the  International 
Standards  Organization  (ISO)  reference  model.  Host  standards  for  internetwork  routing  and  the 
higher  layers  are  required  so  that  communicating  hosts  can  interoperate.  Lower-layer  standards 
depend  on  the  particular  network  interface.  Base  standards  for  host  applications  are  presented  in 
table  3.7-2. 

3.7.2.1.1  Standards.  Base  standards  for  host  applications  are  presented  in  table  3.7-2. 


TABLE  3.7-2  Application  support  standards  for  hosts 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

[PC 

IAB 

Host  Requirements 

Standard  3/RFC- 
1122/RFC-1123 

Mandated 

(Approved) 

[PC 

IAB 

TELNET  Protocol 

Standard  8/RFC- 
854/RFC-855 

Mandated 

(Approved) 

[PC 

IAB 

File  Transfer  Protocol 

Standard  9/RFC- 
959 

Mandated 

(Approved) 

CPC 

IETF 

Network  Time  Protocol  (V3) 

RFC  1305:1992 

Mandated 

(Approved) 

CPC 

IETF 

Hypertext  Transfer  Protocol  -  HTCWl  .0 

RFC  1945:1996 

Mandated 

(Approved) 

GPC 

DOD 

IjyBHSfiBHl 

ACP  123  US 
Supplement  No,  1 

Mandated 

(Approved) 

IPC 

ITU-T 

The  Directory  -  Overview  of  Concept!,  Models  end 
Services  -  Data  Communication  Networks  Directory,  1993 

X.500 

Mandated 

(Approved) 

OPC 

DOD 

Connectionless  Dau  Transfer  Application  Layer  Standard, 
July  27, 1995 

M1L-STD-2045- 

47001 

Mandated 

(Approved) 

3.7.2. 1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.2.1.3  Standards  deficiencies.  The  Directory  Implementor's  Guide,  Version  9,  April  1996, 
provides  reported  defects  and  their  resolutions  to  the  1988  and  1993  editions  of  the  ITU-T 
Recommendations  X.500.  It  also  includes  all  approved  and  draft  corrigenda  to  both  editions  of 
the  directory  specification. 

3.7.2.1.4  Portability  caveats.  X.500  implementations  based  on  1988  and  1993  specifications  will 
not  interoperate  if  the  resolution  of  defect  052  to  the  1988  specification,  which  provides  for 
version  negotiation  and  rules  for  extensibility,  has  not  been  incorporated. 
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3.7.2. 1  £  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  1AB  STD  27,  Telnet  binary  transmission,  5/1/83. 

2.  IAB  STD  28,  Telnet  echo  option,  5/1/83. 

3.  IAB  STD  32,  Telnet  extended  options:  List  option,  5/1/83. 

4.  RFC  1495,  Mapping  between  X.400  and  RFC-822  Message  Bodies,  8/26/93. 

5.  RFC  1415,  FTP-FTAM  gateway  specification,  1/27/93. 

6.  RFC  1708,  NTP  PICS  PROFORMA  for  the  Network  Time  Protocol,  Version  3, 
10/26/94. 

7.  IAB  STD  10,  SMTP  service  extensions,  1 1/6/95. 

8.  RFC  1830,  SMTP  Service  Extensions  for  Transmission  of  Large  and  Binary 
MIME  Messages,  8/1 6/95. 

3.7.2. 1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  The  standard  for  electronic-mail  support,  used  by  the  Defense  Message  System 
(DMS),  is  the  International  Telecommunications  Union  -  Telecommunication 
Standardization  Sector  (ITU-T)  X.400-based  suite  of  military  messaging  standards 
defined  in  Allied  Communication  Publication  (ACP)  123,  U.S.  Supplement  No.  1. 
The  U.S.  Supplement  contains  standards  profiles  that  define  the  DMS  "Business 
Class  Messaging"  (P772)  capability  and  the  Message  Security  Protocol  (MSP). 

The  DMS  will  interface  to  SMTP  by  using  multifunction  interpreters  (MFI).  Some 
loss  of  functionality  will  occur  when  a  gateway  is  used. 

b.  The  X.500  protocol  supports  individual  and  organizational  directory  services  and 
is  mandated  for  use  with  DMS,  X.500  supports  directory  services  that  may  be 
used  by  users  or  host  applications  to  locate  other  users  and  resources  on  the 
network.  X.500  also  supports  security  services  used  by  DMS-compliant  X.400 
implementations. 

c.  The  File  Transfer  Protocol  (FTP)  will  be  used  in  support  of  basic  file  transfer. 

FTP  provides  a  reliable,  file  transfer  service  for  text  or  binary  files. 

d.  Basic  remote  terminal  services  are  supported  by  the  Telecommunications  Network 
(TELNET)  protocol.  TELNET  provides  a  virtual  terminal  capability  that  allows 
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users  to  log  on  to  remote  systems  as  if  the  user's  terminal  were  directly  connected 
to  the  remote  system. 

e.  LAB  STD  3,  an  umbrella  standard,  references  other  documents  and  corrects  errors 
in  some  of  the  referenced  documents.  LAB  STD  3  also  adds  additional  discussion 
and  guidance  for  implementors. 

f.  RFC  1303  specifies  the  mechanisms  to  synchronize  time  and  coordinate  time 
distribution  in  a  large,  diverse  internet 

g.  RFC  1945  specifies  methods  for  search  and  retrieval  within  the  World  Wide  Web. 

h.  MIL-STD-2045-47001  supports  VMF  message  transmission  using  a 
connectionless  application  layer. 
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3.7.2 2  Information  transport.  Information-transport  services  provide  host-to-host 
communications  capability  for  application-support  services. 

3.7.2 .2.1  Standards.  Base  standards  for  information  transport  are  shown  in  table  3.7-3. 


TABLE  3.7-3  Host  standards  for  information  transport 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Holt  Requirement! 

Standard  3/RFC- 
1 122/RFC- H  23 

Mandated 

(Approved) 

IPC 

IAB 

Internet  Protocol 

f§| 

Mandated 

(Approved) 

IPC 

IAB 

Uier  Datagram  Protocol 

Standard  6/RFC- 
768 

Mandated 

(Approved) 

IPC 

IAB 

Transmission  Control  Protocol 

Standard  7/RFC- 
793 

Mandated 

(Approved) 

IPC 

IAB 

ISO  Traiupott  Service  on  top  of  the  TCP 

Standard  35/RFC- 
1006 

Mandated 

(Approved) 

GPC 

DOD 

Internet  Transport  Profile  for  DoD  Communications  • 
Transport  and  Internet  Services 

MIL-STD-2045- 

14502-1 A 

Mandated 

(Approved) 

IPC 

ISO 

Connection  Oriented  Transport  Layer  Specification  (for 
TPOonJy) 

ISO  8073 

Ut«cy 

(Approved) 

IPC 

ISO 

X.2S  Packet  Level  Protocol  for  DTE 

ISO  8208 

Legacy 

(Approved) 

IPC 

ISO 

U«e  of  X.25  to  Provide  the  CONS 

ISO  8878 

Legacy 

(Approved) 

CPC 

IETF 

IPv6  Specification 

RFC  1883:1995 

Emerging 

(Approved) 

CPC 

IETF 

_ 

ICMPv6  for  IPv6 

RFC  1885:1995 

Emerging 

(Approved) 

(Dnai 

XI. 2.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 


3.7.2.23  Standards  deficiencies.  IPv4  does  not  provide  security  features  such  as  authentication 
and  privacy. 

3.7.2.2.4  Portability  caveats.  There  are  many  RFCs  that  specify  extensions  to  TCP.  Most 
vendors'  products  contain  extensions.  To  maximize  portability,  reduce  the  use  of  extensions  as 
much  as  possible. 

3.7.2.2.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 
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1.  RFC  1693,  An  extension  to  TCP:  Partial  Order  Service,  1 1/1/94. 

2.  RFC  1644,  T/TCP  -  T  7P  Extensions  for  Transactions  Functional  Specification, 
7/13/94. 

3.  RFC  1323,  TCP  Extensions  for  High  Performance,  5/13/92. 

4.  RFC  1 144,  Compressing  TCP/IP  headers  for  low-speed  serial  links,  2/1/90. 

5.  RFC  1072,  TCP  extensions  for  long-delay  paihs,  10/1/88. 

6.  RFC  1240,  OSI  Connectionless  Transport  Services  on  Top  of  UDP  -  Version  1, 
3/26/91. 

3J.2.2.6  Recommendations.  The  followmo  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  IAB-STD-7  specifies  the  Transmission  Control  Protocol  (TCP).  TCP  is  the 
standard  Cransport-level  protocol  most  commonly  used  and  is  the  protocol  upon 
which  many  application-support  protocols  depend.  TCP,  as  mandated  by  JTA, 
implements  the  PUSH  flag  and  the  Nagle  Algorithm  defined  in  IAB-STD-3. 

b.  LAB-STD-6  specifies  the  User  Datagram  Protocol  (UDP).  UDP  is  an  alternative 
transport-level  protocol  that  provides  an  unacknowledged,  connectionless, 
datagram  transport  service. 

c.  IAB-STD-5  specifies  the  Internet  Protocol  (IP).  RFCs  corresponding  to  this 
standard  are  referenced  in  table  3.7-1.  Both  TCP  and  UDP  use  the  IP  to  transport 
information  across  internetworks.  IP  supports  connectionless  datar,i  im  service. 
All  protocols  within  the  IP  suite  use  IP  datagrams  as  the  basic  data  transport 
mechanism.  Two  other  protocols  ate  considered  integral  parts  of  IP:  the  Internet 
Control  Message  Protocol  (ICMP)  and  the  Internet  Group  Management  Protocol 
(IGMP).  ICMP  is  used  to  provide  error  reporting,  flow  control,  and  route 
redirection.  IGMP  provides  multicast  extensions  for  hosts  to  report  their  group 
rnen.oership  to  multicast  routers.  In  addition,  all  implementations  of  IP  must  pass 
received  type-of-service  (TOS)  values  up  to  die  transport  layer. 

d.  MIL-STD-2045-14502-1A  specifies  a  military-unique  IP  option  field  that  must  be 
used  for  hosts  that  are  required  to  transmit  or  receive  muitiaddressed  datagrams 
over  combat  net  radio  (CNR). 

1AB-STD-35  supports  interworking  between  Transport  Protocol  Class  0  (TPO) 
and  TCP  transport  service  when  i<  '  >  necessary  for  Open  Systems  Interconnection 
(OSI)  applications  to  operate  over  IP-based  networks.  TPO  is  defined  by  ISO 
8073. 

f.  ISOs  8208  and  8878  are  layer  3  standards  for  legacy  X.25  network  interfaces. 

g.  RFC  1883  specifies  a  new  version  of  IP  (IPv6),  which  has  been  approved  by  the 
Internet  Engineering  Task  Force  (IETF).  The  current  version  of  IP  (IPv4) 
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provides  only  32  bus  of  address  space  and  is  facing  an  inability  to  provide  unique 
addresses  at  all  entities  that  require  them.  RFC  1885  specifies  a  new  internet 
control  message  protocol  for  IPv6.  The  changes  from  IPv4  to  IPv6  are  primarily 
in  the  following  categories: 

•  expanded  addressing  capabilities 

•  header  format  simplification 

•  improved  support  for  extensions  and  options 

•  flow  labeling  capability 

•  authentication  and  privacy  capabilities. 

h.  RFC  1933  specifies  IPv4  compatibility  mechanisms  that  can  be  implemented  by 
IPv6  hosts  and  routers.  These  mechanisms  are  designed  to  allow  IPv6  nodes  to 
maintain  complete  compatibility  with  IPv4. 
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3.7.2J  Domain  name  system  and  internet  protocol  addressing.  Domain  Name  System 
(DNS),  an  on-line  distributed  database  system,  is  used  to  map  human-readable  machine  names 
into  IP  addresses.  DNS  servers  throughout  the  interconnected  internet  implement  a  hierarchical 
name  space  that  allows  sites  freedom  in  assigning  machine  names  and  addresses. 

3.123.1  Standards.  Base  standards  relevant  to  Domain  Name  System  (DNS)  and  IP  Addressing 
are  presented  in  table  3.7-4. 


TABLE  3.7-4  Domain  name  system  and  IP  addressing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

LAB 

Domain  Name  System 

Standard  13/RFC- 
1034/RFC-I03S 

Mandated 

(Approved) 

CPC 

IETF 

Bootstrap  Protocol 

RFC  951:1915 

Mandated 

(Approved) 

CPC 

IETF 

DHCP  Optical  and  BOOTP  Vendor  Eiumiotu 

RFC  1533:1993 

Mandated 

(Approved) 

CPC 

IETF 

Dynamic  Ho*  Configuration  Protocol  (DC HP) 

RFC  1541:1993 

Mandated 

(Approved) 

CPC 

IETF 

Clarification*  and  Extension*  for  the  Bootstrap  Protocol 

RFC  1542:1993 

Mandated 

(Approved) 

CPC 

IETF 

Uniform  Resource  Locator* 

RFC  1738:1994 

Mandated 

(Approved) 

CPC 

IETF 

Relative  Uniform  Resource  Locator* 

RFC  1808:1995 

Mandated 

(Approved) 

CPC 

IETF 

IPv6  Addressing  Architecture 

RFC  1884:1995 

Emerging 

(Approved) 

kh 

IETF 

DNS  Extensions  to  Support  IPv6 

RFC  1886:1995 

Emerging 

(Approved) 

1 

IETF 

IP  Mobility  Support 

RFC  2002:1996 

Emerging 

(Approved) 

■  - y  .  y* % ,  •  • 

3J.2.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.2.3  J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.3.4  Portability  caveats.  There  are  many  RFCs  that  specify  extensions  to  DNS.  Most 
vendors'  products  contain  extensions.  To  maximize  portability,  reduce  the  use  of  extensions  as 
much  as  possible. 

3.7 .2.3.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

I.  RFC  1887,  An  Architecture  for  IPv6  Unicast  Adcress  Allocation,  1/4/96. 
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2.  RFC  1971,  IPv6  Stateless  Address  Autoconfiguration,  8/16/96. 

3.  RFC  1912,  Common  DNS  Operational  and  Configuration  Errors,  2/28/96. 

4.  RFC  1664,  Using  the  Internet  DNS  to  Distribute  RFC  1327  Mail  Address 
Mapping  Tables,  8/1 1/94. 

5.  RFC  1536,  Common  DNS  Implementation  Errors  and  Suggested  Fixes,  10/6/93. 

6.  RFC  1534,  Interoperation  Between  DHCP  and  BOOTP,  10/8/93. 

3.7.2.3.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  IAB-STD- 13  supports  computer-addressing  services  and  is  mandated  for  IP-based 
services.  The  DNS  translates  between  host  names  and  IP  addresses. 

b.  RFC-951  specifies  the  Bootstrap  Protocol  (BOOTP),  which  assigns  IP  addresses 
to  workstations  with  no  current  IP  address. 

c.  RFCs  1533, 1541,  and  1542  specify  the  Dynamic  Host  Configuration  Protocol 
(DHCP),  which  provides  an  extension  of  BOOTP  to  support  the  passing  of 
configuration  information  to  internet  hosts.  DHCP  consists  of  two  parts,  a 
protocol  for  delivering  host-specific  configuration  parameters  from  a  DHCP  server 
to  a  host  and  a  mechanism  for  automatically  allocating  IP  addresses  to  hosts. 

d.  RFCs  1738  and  1808  specify  th«-  Uniform  Resource  Locator  (URL)  for  locating 
resources  on  an  internet. 

e.  RFC  1884  defines  the  addressing  architecture  of  the  IP  Version  6  protocol  (IPv6). 
RFC  1886  defines  the  changes  that  need  to  be  made  to  the  Domain  Name  System 
to  support  hosts  running  IPv6. 

f.  RFC  2002  specifies  protocol  enhancements  that  allow  transparent  routing  of  IP 
datagrams  to  mobile  nodes  in  the  Internet.  "Mobility  Support  in  IPv6"  is  an 
internet  draft  that  specifies  the  operation  of  mobile  computers  using  IPv6. 
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3.7.2.4  Network  management  for  hosts.  The  objective  of  network  management  is  to  support 
the  establishment,  reconfiguration,  and  maintenance  of  a  stable  signaling  and  user-to-network 
environment 

3. 7.2. 4.1  Standards.  Base  standards  for  network  management  of  hosts  are  presented  in  table 
3.7-5. 


TABLE  3.7-5  Host  standards  for  network  management 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Simple  Network  Management  Protocol  (SNMP) 

Standard  15/RFC- 
1157 

Mandated 

(Approved) 

IPC 

IAB 

Structure  of  Management  Information  (SMI) 

Standard  16/RFC- 
1155/RFC- 1212 

Mandated 

(Approved) 

IPC 

IAB 

Management  Information  Baae 

Standard  17/RFC- 
1213 

Mandated 

(Approved) 

CPC 

IETF 

RFC  1902:1996 

Informational 

(Approved) 

CPC 

RFC  1904:1996 

Informational 

(Approved) 

CPC 

1L  '  Protocol  for  Operation*  for  Venion  2  of  the  Simple 

Network  Management  Protocol 

RFC  1905:1996 

Informational 

(Approved) 

CPC 

IETF  '  i-  *gement  Information  Baae  for  Vernon  2  of  the  Simple 

1  Network  Management  Protocol 

RFC  1907:1996 

Informational 

(Approved) 

3.7.2.4.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.2.4J  Standards  deficiencies.  The  chief  disadvantage  of  SNMPvl  is  the  fact  that  its 
simplicity  severely  limits  the  protocol's  ability  to  satisfy  users'  requirements  for  event  reporting, 
sufficient  control,  and  extensibility.  Because  SNMPvl  is  so  simplistic  and  limited,  it  provides 
more  of  a  monitoring  and  data  gathering  capability  than  a  management  function. 

The  SNMPvl  accommodates  only  limited  event  reporting  by  means  of  the  "trap"  mechanism. 
Other  events  must  be  discovered  by  the  managing  node  by  means  of  periodic  polling.  Its 
simplicity  compromises  its  ability  to  support  consistent  or  extensive  addressing.  It  has  limited 
security  capabilities,  and  does  not  support  threshold-driven  performance  notification  except 
indirectly  through  side  effects  or  "set"  operations  on  MIB  items.  SNMP  cannot  be  extended 
easily. 

3.7.2.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2.4.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 
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1.  RFC  1908,  Coexistence  between  Version  1  and  Version  2  of  the  Internet-standard 
Network  Management  Framework,  1/22/96. 

2.  RFC  1461,  SNMP  MIB  Extension  for  Multiprotocol  Interconnect  over  X.25, 
5/27/93. 

3.  RFC  1449,  Transport  Mappings  for  Version  2  of  the  Simple  Network 
Management  Protocol  (SNMPv2),  5/3/93. 

4.  RFC  1446,  Security  Protocols  for  Version  2  of  the  Simple  Network  Management 
Protocol  (SNMPv2),  5/3/93. 

5.  RFC  1445,  Administrative  Model  for  Version  2  of  Simple  Network  Management 
Protocol  (SNMPv2),  5/3/93. 

6.  RFC  1443,  Textual  Conventions  for  Version  2  of  Simple  Network  Management 
Protocol  (SNMPv2),  5/3/93. 

7.  RFC  1441,  Introduction  to  Version  2  of  the  Internet-standard  Network 
Management  Framework,  5/3/93. 

X12A.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  Hosts  will  use  the  Simple  Network  Management  Protocol  (SNMP)  set  of  network 
management  protocols.  SNMP  vl  is  specified  in  1AB-STD-15,  -16,  and  -17. 

b.  SNMP  v2  adds  security  and  authentication  capabilities  and  a  new  manager-to- 
manager  relationship  for  distributed  management.  SNMP  v2,  which  is  backward- 
compatible  with  SNMP  vl,  is  specified  in  RFCs  1902,  1904,  1905,  and  1907. 
SNMP  v2  has  not  been  accepted  by  the  industry,  and  few  vendors  include  SNMP 
v2  in  their  products.  The  main  complaints  focus  on  the  complex  design  of  the 
security  and  administrative  framework.  The  IETF  is  presently  working  on  a  next 
generation  version  called  SNMPng.  The  first  set  of  internet-drafts  are  expected  in 
the  Spring  of  1997. 
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3.7.2.S  Video  teleconferencing.  DOD  and  the  video  teleconferencing  (VTC)  industry  have 
developed  a  profile  to  provide  a  standards-based  reference  document  for  users  as  an  aid  in 
defining  procurement  specifications  for  VTC  equipment 

3.7.2 .5.1  Standards.  Base  standards  for  VTC  are  presented  in  table  3.7-6. 


TABLE  3.7-6  VTC  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Induatry  Profile  for  Video  Teleconferencing 

VTC001,  Revision 

1,  April  25, 1995 

Mandated 

(Approved) 

IPC 

ITU-T 

Terminal  for  Low  Bit  Rale  Multimedia  Communication! . 
March  19, 1996 

H.324 

Mandated 

(Approved) 

IPC 

ITU-T 

VTC  over  ATM 

H.321 

Emerging 

(Approved) 

IPC 

ITU-T 

VTC  over  Ethernet 

H.323 

Emerging 

(Approved) 

-v-  .v  uSTOMJl  1 

;  '.„<K  >  'v  ■"■■'if 

3.7.2.S.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 


3.7.2.5J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.S.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 .2.5 5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  FIPS  PUB  178,  Video  Teleconferencing  Services  at  56  to  1,920  Kb/s,  1992. 

2.  ANSI  T1.314,  Digital  Processing  of  Video  Signals  -  Video  Coder/Decoder  for 
Audiovisual  Services  at  56  to  1536  kbits/s,  1991. 

3.  ANSI  Tl. 801.01,  Telecommunications  -  Digital  Transport  of  Video 
Teleconferencing/  Video  telephony  Signals  -  Video  Test  Scenes  for  Subjective  and 
Objective  Performance  Assessment 

4.  RFC  1890,  RTP  Profile  for  Audio  and  Video  Conferences  with  Minimal  Control, 
1/25/96. 

3.7.2.5.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


I 
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a.  VTC  001  applies  to  video  teleconferencing  terminals.  VTC  001  is  based  on  the 
H.320  and  T.120  series  of  recommendations  and  is  independent  of  the  type  of 
underlying  network  service. 

b.  FIPS  PUB  178  is  based  on  the  H.320  series  of  recommendations  but  lacks  the 
additional  DOD  requirements  contained  in  VTC  001 .  The  new  version  of  FIPS 
PUB  178  includes  these  DOD  requirements.  Appendix  A  of  the  FIPS  PUB  178-1 
contains  VTC  001.  FIPS  PUB  178-1  is  awaiting  final  approval  from  NIST.  FIPS 
PUB  178-1  will  replace  VTC  001  as  the  DOD  mandated  standard. 

c.  ITU-T  H.321  and  H.323  are  emerging  standards  that  support  VTC  over  ATM  and 
Ethernet  networks. 

d.  ITU-T  H.324  has  been  mandated  by  the  JTA  for  VTC  terminals  that  operate  at 
low  bit  rates  (9.6  to  28.8  kbps). 
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3.7. 2.6  Facsimile,  facsimile  terminals  may  be  procured  with  either  a  standard  analog  interface  or 
a  standard  digital  interface. 

3.7.2.6.I  Standards.  Base  standards  for  facsimile  are  presented  in  table  3.7-7. 


TABLE  3.7-7  Facsimile  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

ELVTIA 

Grotq>  3  Facsimile  App*;.*u  for  Document  TnosmUtioo, 
Match  21, 1995 

465-A 

Mandated 

(Approved) 

CPC 

E1A/TIA 

Procedure*  for  Document  Facsimile  Trarumisnon 

466-A 

Mandated 

(Approved) 

GPC 

DOD 

Interoperability  and  Performance  Standaids  for  Digital 
Facsimile  Equipment,  January  10, 1995 

MIL- STD- 1&«- 
161 D 

Mandated 

(Approved) 

3.7.2.6.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.2.6  J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2 .6.5  Related  standards.  Related  standards  are  informative  documer 's  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standaids. 

1 .  MIL-STD-188-1 14A,  Electrical  Characteristics  of  Digital  Interface  Circuits, 
12/91. 

2.  STANAG  5000,  Interoperability  of  Tactical  Digital  Facsimile  Equipment. 

3.7 .2.6.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  Facsimile  requirements  for  analog  output  shall  comply  with  ITU-T  Group  3 
specifications  given  in  Electronics  Industries  Association/Telecommunications 
Industry  Association  (E1A/TIA)  Standards  465-A  and  466-A. 

b.  Digital  facsimile  terminals  operating  in  tactical,  high  bit  error  ratio  (BER) 
environments  shall  implement  digital  facsimile  equipment  standards  for  Type  I, 
Type  II,  or  both,  modes  specified  in  MIL-STD- 188-161 D.  Facsimile  transmissions 
requiring  encryption  shall  also  use  this  military  standard. 
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3.7.2.7  Secondary  imagery  dissemination.  National  Imagery  Transmission  Format  (NITF) 
Standards  (NITFS)  define  the  standard  formats  for  digital  imagery  and  imagery-related  products 
to  be  exchanged  between  members  of  the  Intelligence  Community,  DoD,  and  other  departments 
and  agencies  of  the  United  States  Government.  The  NITFS  includes  supporting  standards  for 
imagery,  image  compression,  other  imagery-related  requirements,  and  the  Tactical 
Communications  2  (TAC02)  protocol.  The  document  structure  for  current  and  anticipated 
NITFS  documentation  is  described  in  MIL-HDBK-1300A. 

3.7.2.7.1  Standards.  Base  standards  for  secondary  imagery  dissemination  are  presented  in  table 
3.7-8. 


TABLE  3.7-8  Secondary  imagery  dissemination  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

National  Imagery  Tranimiiaion  Standard  (NITFS)  Tactical 
Communication  i  Protocol  2  (TAC02),  June  18, 1993 

KflL-STD-2045- 

44500 

Mandated 

(Approved) 

GPC 

DOD 

National  Imagety  Traiumiuion  Format  (Version  2.0)  for 
file  format 

MIL-STD-2500A 

Mandated 

(Approved) 

GPC 

DOD 

Bi-Level  Image  Compression 

MIL-STD-188-196 

Mandated 

(Approved) 

GPC 

DOD 

Joint  Photographic  Expert!  Group  (JPEG)  Image 
Comprcsiion  for  the  NITFS  (for  Gray  Scale  and  Still  Color 
Image!) 

M3L-STD-188- 
198  A  of 
12/15/1993 

Mandated 

(Approved) 

GPC 

DOD 

Vector  Quantization  (VQ)  Decompression 

MJL-STD-188-199 

Mandated 
(Approvr  I) 

GPC 

DOD 

B5HIB 

— 

U8»cy 

(Approved) 

3.7.2.7.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.2.7.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2.7.5  Related  stai  lards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

MIL  HDBK-1300A,  National  Imagery  Transmission  Format  Standard,  10/12/94. 

3.7.2.7.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  M1L-STD-2045-44500  is  the  standard  mandated  for  Tactical  Communications 

Protocol  2  (TAC02).  TAC02  is  the  communications  component  of  the  National 
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Imagery  Transmission  Format  Standard  (NTTFS)  suite  of  standards  used  to 
disseminate  secondary  imagery.  TAC02  supports  operation  over  point-to-point 
tactical  data  links  in  high  BER  communications  environments.  TAC02  applies 
only  to  users  that  have  simplex  and  half-duplex  links  as  their  only  means  of 
communications. 

b.  MIL-STD-2500A  is  the  NITF  Standard  that  provides  a  detailed  description  of  the 
overall  structure  of  the  file  format,  as  well  as  specification  of  the  valid  data  content 
and  format  for  all  fields  defined  within  a  NITF  file. 

c.  The  M1L-STD- 188- 196/1 99  series  defines  compression  algorithms  for  imagery. 

For  more  information  on  JPEG  standard  see  ITSG,  part  S,  Data  Interchange 
Services. 
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3.7.2JJ  High-level  data  link  control  protocols.  Link-layer  protocols  based  on  high-level  data 
link  control  (HDLC)  protocols  are  used  by  packet-switched  networks,  hosts,  routers,  and  for 
Narrowband-Integrated  Services  Digital  Network  (N-ISDN)  signaling  messages. 

3.7.2.8.1  Standards.  Base  standards  for  high-level  data  link  control  (HDLC)-based  link-layer 
protocols  are  presented  in  table  3.7-9. 


TABLE  3,7-9  HDLC-based  link-layer  protocol  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-T 

ISDN  U*er- Network  Interface  -  Data  Link  Layer 
Specification  -  Digital  Subscriber  Signaling  Syrian  No.  1, 
1993 

Q.921 

Mandated 

(Approved) 

IPC 

ISO 

HDLC  Frame  Structure* 

3309 

Legacy 

(Approved) 

IPC 

ISO 

HDLC  Element*  of  Procedure* 

4335 

Legacy 

(Approved) 

IPC 

ISO 

X.25  LAPB-Compatible  DIB  Data  Link  Procedure* 

7776 

Legacy 

(Approved) 

IPC 

ISO 

HDLC  Procedure*,  Data-Link  Layer  Addreti 
Retolurioo/Negoriarion  in  Switched  Environment* 

8471 

Legacy 

(Approved) 

IPC 

ISO 

HDLC  Procedure*,  General  Purpoie  XID  Frame 
Information  Field  Content  and  Format 

8885 

Legacy 

(Approved) 

3.7.2.5.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7. 2.8.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.8.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2.8.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

ISO  7809,  Information  Technology  -  Telecommunications  and  Information  Exchange 
Between  Systems  -  High-Level  Data  Link  Control  (HDLC)  Procedures  -  classes  of 
procedures,  Third  Edition. 

3.7.2.8.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

The  X.25  link-layer  protocol,  known  as  link  access  procedure  balanced  (LAPB),  is  a  subset  of 
HDLC  and  uses  the  frame  structure  and  procedures  specified  in  ISO  3309  and  4335.  LAPB  for 
hosts  is  specified  in  ISO  7776.  Link-layer  address  resolution  and  XID  procedures  for  legacy 
packet-switch  networks  is  supported  by  ISO  847 1  and  8885,  respectively. 
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LAPD  is  specified  in  ITU-T  Q.921.  LAPD  is  used  as  a  data  link  control  for  ISDN.  LAPD  differs 
from  LAPB  in  the  following  ways: 

1.  LAPD  is  designed  for  multiple  access  on  the  link.  LAPB  is  intended  for  point-to- 
point  operating. 

2.  LAPD  and  LAPB  use  different  timers. 

3.  The  address  structures  are  different 

4.  LAPD  implements  HDLC  unnumbered  information  frame  (UI).  LAPB  uses  only 
sequenced  information  frames. 
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3.7.2.9  Record  traffic  protocol.  Legacy  formal  record  traffic  systems  are  based  on  legacy 
interoperability  standards.  These  standards  shall  be  supported  until  the  legacy  systems  are 
replaced  by  the  Defense  Message  System  (DMS). 

3.7.2.9.1  Standards.  Base  standards  for  record  traffic  protocols  are  presented  in  table  3.7-10. 


TABLE  3.7-10  Record  traffic  protocol  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

MIL-STD- 188-171 

Ug«cy 

(Approved) 

GPC 

DOD 

MIL-STD-188-172 

te«*cy 

(Approved) 

GPC 

DOD 

2 . 

MIL-STD- 188- 173 

(Approved) 

GPC 

DOD 

MIL-STD-188-174 

Legecy 

(Approved) 

3.7.2.9.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.2.9J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.9.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2.95  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  JANAP  128  Joint  Army/Navy/Air  Force  Publication  128:  AUTODIN  Operating 
Procedures,  March  1983. 

2.  ACP  127  Message  Relay  procedures. 

3.  Digital  Equipment  Corporation  (DEC)  Digital  Data  Communications  Message 
Protocol  (DDCMP). 

3.7.2.9.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

a.  MIL-STD-188-171  will  provide  the  Mode  1  channel  coordination  procedure  for 
synchronous,  simultaneous,  duplex  data  transfer  over  terrestrial  links. 

b.  MIL-STD-188-172  will  provide  the  Mode  II  non-ARQ  channel  coordination 
procedure  for  asynchronous,  simultaneous,  independent,  duplex  data  transfer. 
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c.  MIL-STD-188-173  will  provide  the  Mode  V  ARQ  channel  coordination  procedure 
for  asynchronous,  simultaneous,  independent,  duplex  data  transfer. 

d.  MIL-STD-188-174  will  -ovide  the  Mode  V  ARQ  channel  coordination  procedure 
for  asynchronous,  simultaneous,  duplex  data  transfer. 


3.7-22 
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3.7.2.10  Voice  encoding  for  end  systems.  Several  different  voice  digitization  algorithms  may  be 
used  to  support  digital  voice  applications.  The  method  used  depends  on  available  bandwidth  and 
type  of  interface. 

3.7.2.10.1  Standards.  Base  standards  for  voice  encoding  are  presented  in  table  3.7-1 1. 


TABLE  3.7-11  Voice  encoding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ITU-T 

Pul*e  Code  Modulation  (PCM)  of  voice  frequencie* 
(narrowband) 

G.71 1:1989 

Adopted 

(Approved) 

IPC 

ITU-T 

32  kbit*/*  Adaptive  Differential  Pulte  Code  Modulation 
(ADPCM)  -  General  AipecU  of  Digital  Tranimiirion 
Systems 

G.721:1989 

Adopted 

(Approved) 

GPC 

NCS 

Linear  Predictive  Coding  (LPC) 

FED-STD-1015 

Adopted 

(Approved) 

GPC 

NCS 

Analog-to- Digital  Convent  on  of  Radio  Voice  by  4800-bp« 
Code  Excited  Linear  Prediction  (CELPO 

FED-STD-1016 

Adopted 

(Approved) 

GPC 

DOD 

Analog-to-  Digital  Convenion  Technique*  (for  CVSD 
Modulation) 

MIL- STD- 188-1 13 

Legacy 

(Approved) 

3.7.2.10.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.2.10.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.2.10.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.2.10J5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ANSI  T1.302,  Telecommunications  -  Digital  Processing  of  Voice-Band  Signals  - 
Line  Format  for  32-kbits/s  Adaptive  Differential  Pulse-Code  Modulation 
(ADPCM). 

2.  ANSI  T1.310,  Telecommunications  -  Digital  Processing  of  Voice-Band  Signals  - 
Algorithms  for  5-.  4-,  3-,  and  2-bit/Sample  Embedded  Adaptive  Differential  Pulse- 
Code  Modulation  (ADPCM). 

3.  ANSI  T1.501,  Telecommunications  •  Network  Performance  -  Tandem  Encoding 
Limits  for  32  kbits/s  Adaptive  Differential  Pulse-Code  Modulation  (ADPCM). 

3.7.2.10.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 
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a.  ITU-T  0.1 1 1  specifies  64-kbps  pulse-code  modulation  (PCM)  for  both  mu-law 
and  A-law  companding. 

b.  MIL-STD-188-1 13  specifies  16-kbps  continuously  variable  slope  delta  (CVSD) 
modulation. 

c.  FED-STD-1015  specifies  2.4-kbps  linear  predictive  coding  (LPC). 

d.  FED-STD-1016  specifies  4.8-kbps  code-excited  linear  prediction  (CELP). 

e.  ITU-T  G.721  specifies  32-kbps  adaptive  differential  pulse-code  modulation 
(ADPCM). 
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3.7 3  Communications  services  for  networks.  This  section  addresses  standards  for  different 
types  of  networks  and  other  network-related  topics.  Networks  include  router  networks,  local  area 
networks  (LANs),  packet  switch,  point-to-point,  combat  net  radio,  N-ISDN,  broadband-lSDN 
(B-ISDN),  and  the  asynchronous  transfer  mode  (ATM).  Network-related  topics  include  voice 
digitization,  timing  and  synchronization,  network  management,  interworking,  and  personal 
communications  services. 

3.7.3. 1  Routers.  IP  routers  perform  internetwork  routing.  They  also  perform  interface  functions 
needed  to  pass  packets  between  different  networks.  IP  routers  route  packets  based  on  destination 
subnetwork  addresses,  not  destination  end-system  addresses.  IP  routers  may  exist  any  place 
within  the  Defense  Information  Systems  Network  (DISN)  as  either  interior  or  exterior  gateways. 
For  the  purpose  of  routing,  a  group  of  networks  and  gateways  controlled  by  a  single 
administrative  authority  is  called  an  autonomous  system,  which  uses  interior  gateway  protocols. 
Gateways  between  autonomous  systems  use  exterior  gateway  protocols. 

3.7  J. 1.1  Standards.  Base  standards  for  routers  are  presented  in  table  3.7-12. 


TABLE  3.7-12  Router  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Internet  Protocol 

Standard  5/RFC- 
791/RFC- 
95(YRFC- 
919/RFC- 
922/RFC- 
792/RFC-l  1 12 

Mandated 

(Approved) 

IPC 

IAB 

User  Datagram  Protocol 

Standard  6/RFC- 
768 

Mandated 

(Approved) 

IPC 

IAB 

Transmission  Control  Protocol 

Standard  7/RFC- 
793 

Mandated 

(Approved) 

IPC 

IAB 

TELNET  Protocol 

Standard  8/RFC- 
854/RFC-855 

Mandated 

(Approved) 

IPC 

IAB 

Domain  Name  System 

Standard  13/RFC- 
1034/RFC-1035 

Mandated 

(Approved) 

IPC 

IAB 

Simple  Network  Management  Protocol  (SNMP) 

Standard  15/RFC- 
1157 

Mandated 

(Approved) 

IPC 

IAB 

Structure  of  Management  Information  (SMI) 

Standard  16/RFC- 
11 55/RFC- 12 12 

Mandated 

(Approved) 

IPC 

IAB 

Management  Information  Base 

Standard  17/RFC- 
1213 

Mandated 

(Approved) 

IPC 

IAB 

Trivial  FTP  (TFTP),  to  be  used  for  initialization  only. 

Standard  33/RFC- 
1350 

Mandated 

(Approved) 

CPC 

IETF 

Bootstrap  Protocol 

RFC  951:1985 

Mandated 

(Approved) 

CPC 

IETF 

DHCP  Options  and  BOOTP  Vendor  Extensions 

RFC  1533:1993 

Mandated 

(Approved) 

CPC 

IETF 

Dynamic  Host  Configuration  Protocol  (DCHP) 

RFC  1541:1993 

Mandated 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

IETF 

Qanfkationi  and  Extensions  for  the  Bootstrap  Protocol 

RFC  1542:1993 

Mandated 

(Approved) 

CPC 

IETF 

Open  Shortest  Path  First  Rotfing  Vernon  2,  for  unicast 
routing 

RFC  1583:1994 

Mandated 

(Approvod) 

CPC 

IETF 

Multicast  Extensions  to  QSPF  for  multicast  routing 

RFC  1584:1994 

Mandated 

(Approved) 

CPC 

IETF 

Border  Gateway  Protocol  4 

RFC  1771:1995 

Mandated 

(Approved) 

CPC 

IETF 

Application  of  BGP  In  the  Internet 

RFC  1772:1995 

Mandated 

(Approved) 

CPC 

IETF 

Requirements  for  IP  Version  4  Routers 

RFC  1812:1995 

Mandated 

(Approved) 

CPC 

IETF 

IPv6  Specification 

RFC  1883:1995 

Emerging 

(Approved) 

CPC 

IETF 

IPv6  Addressing  Architecture 

RFC  1884:1995 

Emerging 

(Approved) 

CPC 

IETF 

ICMPv6  for  IPv6 

RFC  1885:1995 

Emerging 

(Approved) 

CPC 

IETF 

DNS  Extensions  to  Support  IPv6 

RFC  1886:1995 

Emerging 

(Approved) 

3.7.3.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.3.1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 


3.7 .3.1.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  RFC  1970,  Neighbor  Discovery  for  IP  Version  6  (IPV6),  8/16/96. 

2.  RFC  1933,  Transition  Mechanisms  for  IPv6  Hosts  and  Routers,  4/8/96. 

3.7 .3.1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  The  following  standards  and  RFCs  that  were  mandated  for  hosts  in  section  3.7.2. 1 
also  apply  to  routers:  IAB-STD-5,  -6,  -7,  -8,  -13,  -15,  -16,  and  -17,  aro  RFCs 
0951,  1533,  1541,  1542,  1883,  1884,  1885,  and  1886. 

b.  IAB-STD-33  specifies  the  trivial  file  transport  protocol,  which  is  used  by  routers 
for  initialization  only. 
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c.  RFC  1583  specifies  the  open  shortest  path  first  (OSPF)  version  2  protocol  for 
unicast  interior  gateway  routing;  RFC  1584  specifies  multicast  OSPF  (MOSPF)  for 
multicast  interior  gateway  routing. 

d.  RFCs  1771  and  1772  specify  the  gateway  protocol  used  by  routers  for  exterior 
gateway  routing. 

e.  RFC-1812,  an  umbrella  standard,  references  other  documents  for  IPv4  and 
corrects  errors  in  some  of  the  reference  documents. 
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3.7.3 2  Local  area  networks.  Local  Area  Networks  (LANs)  provide  connectionless  subnetwork 
service  to  support  information  exchange  between  end  systems.  The  information  transfer  can  be 
point-to-point,  multicast,  or  broadcast  The  link  layer  consists  of  two  sublayers,  logical  link 
control  (LLC)  and  media  access  control  (MAC).  Link-layer  addresses  are  used  to  exchange 
information  between  end  systems  on  the  same  LAN.  IP-layer  addresses  are  required  for 
information  to  be  exchanged  with  end  systems  on  LANs  connected  to  other  networks. 

3.7.3.2.1  Standards.  Base  standards  for  LANs  are  presented  in  table  3.7-13. 


TABLE  3.7-13  LAN  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

8802-3:1993 

Mandated 

(Approved) 

IPC 

IAB 

An  Ethernet  Add  real  Resolution  Protocol 

Standard  37/RFC- 
826 

Mandated 

(Approved) 

IPC 

IAB 

Standard  for  the  Transmission  of  IP  Datagram!  Over 
Ethernet  Network! 

Standard  41 /RFC- 
894 

Mandated 

(Approved) 

IPC 

ISO 

Logical  Link  Control 

8802-2 

Adopted 

(Approved) 

IPC 

IAB 

A  Reverie  Address  Resolution  Protocol  (RARE) 

Standard  38/RFC- 
903 

Adopted 

(Approved) 

IPC 

ISO 

Fiber  Distributed  Data  Interface  (FDD!) 

9314 

Adopted 

(Approved) 

NPC 

ANSI 

FDD1  Station  Management 

X3.229 

Adopted 

(Approved) 

IPC 

ISO 

Token  Bus  Media  Access  Control 

8802-4 

Legacy 

(Approved) 

IPC 

ISO 

Token  Ring  Media  Access  Control 

8802-5 

Legacy 

(Approved) 

NPC 

IEEE 

Fast  Ethernet 

802.3u 

Emerging 

(Approved) 

l|§§g|fll 

SUB 

3.7.3.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 


3.7.3.2.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.2.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 
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1 .  ISO  8473-2,  Information  Technology  -  Protocol  for  Providing  the  Connectionless- 
Mode  Network  Service  -  Part  2:  Provision  of  the  Underlying  Service  by  an 
ISO/IEC  8802  Subnetwork,  First  Edition. 

2.  ANSI/IEEE  802. IB,  Information  Technology  -  Telecommunications  and 
Information  Exchange  Between  Systems  -  Local  and  Metropolitan  Area  Networks 
-  Common  Specifications  -  Part  2:  LAN/MAN  Management 

3.  IEC  847,  Characteristics  of  Local  Area  Networks  (LAN),  First  Edition. 

4.  ISO  ISP  10608-4,  Information  Technology  -  International  Standardized  Profile 
TAnnn  -  Connection-Mode  Transport  Service  over  Connectionless-Mode 
Network  Service  -  Part  4:  Definition  of  Profile  TA53,  Operation  over  a  Token 
Ring  LAN  Subnetwork,  First  Edition. 

5.  ISO  ISP  10608-6,  Information  Technology  -  International  Standardized  Profile 
TAnnn  -  Connection-Mode  Transport  Service  over  Connectionless-Mode 
Network  Service  -  Part  4:  Definition  of  Profile  TA54,  Operation  over  an  FDDI 
LAN  Subnetwork,  First  Edition. 

6.  ISO  ISP  10609-11,  Information  Technology  -  International  Standardized  Profiles 
TB,  TC,  TD,  and  TE  -  Connection-Mode  Transport  Service  over  Connectionless- 
Mode  Network  Service  -  Part  11:  CSMA/CD  Subnetwork  -  Dependent,  Media- 
Dependent  Requirements,  First  Edition. 

7.  ISO  TR  10178,  Information  Technology  -  Telecommunications  and  Information 
Exchange  Between  Systems  -  the  Structure  and  Coding  of  Logical  Link  Control 
Addresses  in  Local  Area  Networks,  First  Edition. 

3.7 .3.2.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  ISO-8802-2  specifies  the  LLC  protocols  used  in  LANs  such  as  ISO  8802-3 
(CSMA-CD),  ISO  8802-4  (token  bus),  and  ISO  8802-5  (token  ring).  The  link 
service  provided  over  ISO-8802  LANs  shall  be  a  Type- 1  connectionless  network 
service,  as  defined  in  ISO-8802-2.  The  LLC  generates  command  packets  (or 
frames)  called  protocol  data  unUs  (PDU)  and  interprets  them. 

b.  The  MAC  sublayer  handles  the  methods  for  allowing  a  particular  node  to  transmit 
on  the  specific  data  transmission  media  available  to  it  A  LAN  can  be  configured 
as  either  a  bus  or  a  ring  topology.  Two  primary  methods  are  used  to  control 
access:  carrier  sense  multiple  access/collision  detection  (CSMA/CD)  and  token 
passing.  The  ISO  8802-3  standard  addresses  CSMA/CD,  ISO  8802-4  addresses 
token-passing  buses,  and  ISO  8802-5  addresses  token-passing  ring.  ISO  9314 
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addresses  Fiber  Distributed  Data  Interface  (FDDI)  LANs.  For  interoperability 
reasons,  the  JTA  mandates  support  for  only  one  type  of  LAN. 

c.  ANSI  X3.229  specifies  the  Station  Management  standards  for  FDDI  LANs. 

d.  LAB-STD-37  and  LAB-STD-38  specify  the  Address  Resolution  Protocol  (ARP) 
and  Reverse  ARP  (RARP),  which  are  needed  for  resolution  of  IP-layer  and  link- 
layer  addresses. 

e.  IAB-STD-41  specifies  a  standard  method  of  encapsulating  IP  datagrams  on  an 
Ethernet. 

f.  For  high-speed  LAN  requirements,  100-Mbps  Ethernet  technology  may  be 
implemented  in  accordance  with  IEEE  802.3u.  This  standard  supports  auto¬ 
negotiation  of  the  media  speed,  making  it  possible  for  dual-speed  Ethernet 
interfaces  to  run  either  at  10  or  100  Mbps  automatically. 

g.  The  IEEE  802. 1 1  Committee  is  developing  emerging  standards  for  wireless  LAN 
services  across  three  transmission  media:  spread-spectrum  radio,  narrowband 
radio,  and  infrared.  Wireless  technology  is  useful  in  environments  requiring  user 
mobility  or  flexible  network  establishment  and  reconfiguration. 
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3.7.33  Packet-switch  services.  Packet  switch  services  are  supported  by  both  wide  area  packet- 
switched  network  standards  and  internet  standards. 

3.733.1  Standards.  Base  standards  for  packet  switches  are  presented  in  table  3.7-14. 


TABLE  3.7-14  Packet-switch  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

NPC 

ANSI 

Core  Atpecti  of  Frame  Protocol  for  Uie  with  Frame  Relay 
Bearer  Service 

T1.618 

Adopted 

(Approved) 

EPC 

ITU-T 

X.25 

Leg** 

(Approved) 

IPC 

ITU-T 

Packet-Switched  Signaling  Syrian  Between  Pubbc 
Networiu  Providing  Data  Tranuniuion  Service* 

X.75 

Legacy 

(Approved) 

IPC 

ITU-T 

International  Numbering  Plan  for  Public  Data  Network* 

X.121 

Legacy 

(Approved) 

CPN-C 

Bellcore 

Generic  Switching  Requirement*  in  Support  of  SMDS 

TR-TSV-000772 

Informational 

(Approved) 

3.7.33 2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.3.33  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.733.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.733.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ISO  8878,  Information  Technology  -  Telecommunications  and  Information 
Exchange  Between  Systems  -  Use  of  X.25  to  Provide  the  OSI  Connection-Mode 
Network  Service,  Second  Edition. 

2.  ISO  10588,  Information  Technology  -  Use  of  X.25  Packet  Layer  Protocol  in 
Conjunction  with  X.21/X.21  is  to  provide  the  OSI  Connection-Mode  Network 
Service,  First  Edition. 

3.  ISO  8881,  Information  Processing  Systems  -  Data  Communications  -  Use  of  the 
X.25  Packet  Level  Protocol  in  Local  Area  Networks,  First  Edition. 

3.733.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 
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a. 

b. 

c. 

d. 

e. 
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ITU-T  X.25  specifies  the  legacy  packet-switch  interface  to  DTEs  for  both  the  link 
and  packet  layers. 

ITU-T  X.7S  specifies  the  link  and  packet  layer  interface  used  to  interconnect 
legacy  packet-switch  networks. 

ITU-T  X.121  specifies  the  numbering  plan  format  used  by  packet-switch 
networks. 

ANSI  T1.618  specifies  frame  relaying  of  packet-switch  data  using  an  ISDN 
packet-mode  bearer  service. 

Bellcore  TR-TSV-000772  specifies  the  interface  used  to  transport  packet-switch 
data  using  switched  multi-megabit  data  service  (SMDS). 
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3.7 .3.4  Point-to-point  service.  Point-to-point  protocol:  (PPP)  support  full-duplex,  synchronous 
or  asynchronous,  communications  between  end  systems.  Point-to-point  systems  include  physical- 
layer  interfaces  and  a  link-layer  protocol. 

3.7J.4.1  Standards.  Base  standards  for  point-to-point  systems  are  presented  in  table  3.7-15. 


TABLE  3.7-15  Point-to-point  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

IAB 

The  Poiiu-lo-PoW  Protocol  (PPP) 

Standard  51/RFC 
1661 

Mandated 

(Approved) 

CPC 

IETF 

PPP  Internet  Protocol  Control  Protocol  (IPCP) 

RFC  1332:1992 

Mandated 

(Approved) 

CPC 

IETF 

PPP  Link  Quality  Monitoring 

RFC  1333:1992 

Mandated 

(Approved) 

CPC 

IETF 

PPP  Authentication  Protocol! 

RFC  1334:1992 

Mandated 

(Approved) 

CPC 

IETF 

PPP  Link  Control  Protocol  (LCP)  Extensions 

RFC  1570:1994 

Mandated 

(Approved) 

NPC 

EIA 

Interface  Between  Data  TcnnmjJ  Equipment  end  Data 
Circuit  Terminating  Equipment  Employing  Serial  Binary 
Data  Interchange,  July  1991 

232E 

Mandated 

(Approved) 

NPC 

EIA 

General  Purpose  37-Poiition  and  9-Position  Interface  for 
Data  Terminal  Equipment  and  Data  Circuit  Terminating 
Equipment  Employing  Serial  Binary  Data  Interchange, 
February  1980 

449 

Mandated 

(Approved) 

NPC 

EIA 

High  Speed  25-Po»itioo  Interface  for  Data  Terminal 
Equipment  and  Data  Circuit-Terminating  Equipment,  June 
1992,  Including  Alternate  26-Position  Connector,  1992 

530A 

Mandated 

(Approved) 

IPC 

ITU-T 

Data  Transmission  at  48  kbps  Using  60- 108  kHz  Group 
Band  Circuits  (Section  on  NRZ  Interface) 

V.35 

Adopted 

(AR>roved) 

3.7.3.4.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3J.3.4.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3J.3.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.4.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

RFC  1841,  PPP  Network  Control  Protocol  for  LAN  Extension,  9/29/95. 

3.7 .3.4.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 
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a.  IAB-STD-51,  RFC-1332,  RFC-1333,  RFC-1334,  and  RFC-'.  T70  specify  link-layer 
protocols  for  point-to-point  systems. 

b.  EIA-232E,  EIA-449,  EIA-530A,  and  ITU-T  V.35  (secUon  on  NRZ  Interface) 
specify  physical-layer  interfaces  for  point-to-point  systems. 
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3.73.5  Combat  net  radio.  Combat  net  radios  (CNRs)  provide  voice  or  data  communications  for 
mobile  users.  These  r  adios  provide  a  half-duplex  broadcast  transmission  media  with  potentially 
high  BGRs. 

3.7  J.5.1  Standards.  The  base  standard  for  CNR  is  presented  in  table  3.7-16. 


TABLE  3.7-16  Combat  net  radio  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

M2L-STD-I88- 

220A 

Mandated 

(Approved) 

GPC 

DOD 

Interne*  Transport  Profile  for  DoD  Communication*  - 
Transport  and  Internet  Service* 

MIL-STD-2045- 
14502-1 A 

Mandated 

(Approved) 

3.7.3 .52  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.73.53  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 .3.5.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1 .  MIL-STD- 188-11 4A,  Electrical  Characteristics  of  Digital  Interface  Circuits, 

12/91. 

2.  MIL-STD- 1 88-200,  System  Design  and  Engineering  Standard  for  Tactical 
Communication,  6/83. 

3.  ISO  8802-2,  Information  Technology  -  Telecommunications  and  Information 
Exchange  Between  Syu"?  ns  -  Local  and  Metropolitan  Area  Networks  -  Specific 
Requirements  -  Part  2:  Logical  Link  Control,  Second  Edition. 

4.  ISO  8885,  Information  Technology  -  Telecommunications  and  Information 
Exchange  Between  Systems  -  High-L.  ■  '1  Data  Link  Control  (HDLC)  Procedures  - 
General  purpose  X1D  Frame  Information  Field  Content  and  format,  Third  Edition. 

5.  IAB  STD  3,  Requirements  for  Internet  hosts  -  communication  layers,  10/1/89. 

3.7.3.5.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 
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a.  MIL-STD-  188-220A  specifies  the  method  by  which  IP  packets  are  encapsulated 
and  transmitted  over  CNR  subnetworks. 

b.  MIL-STD- 2045- 14502- 1 A  specifies  a  multiaddressed  IP  option  Held  that  must  be 
used  by  hosts  that  are  required  to  transmit  or  receive  multiaddressed  datagrams 
over  CNR. 
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3.7 3.6  N-ISDN.  Narrowband-ISDN  (N-ISDN)  is  based  on  a  64-kbps  channel  structure. 
Channels  used  for  user  information  exchange  are  called  B-channels.  Separate  channels  provided 
for  common-channel  signaling,  called  D-channels,  are  used  to  set  up  connections  and  control 
supplementary  services  (see  3.7.3.7). 

3. 7.3. 6.1  Standards.  Base  standards  for  N-ISDN  are  presented  in  table  3.7-17. 


TABLE  3.7-17  N-ISDN  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

— 

1. 

ANSI 

Telecommunication!  -  Integrated  Service*  Digital  Network 
(ISDN)  -  Primary  Rate  •  Customer  Install'  lion  Metallic 
Interface*  (Layer  1  Specification),  1990 

TI.408 

Mandated 

(Approved) 

NPC 

ANSI 

Telecommunication*  -  Integrated  Service*  Digital  Netwoik 
(ISDN)  -  Basic  Acce*t  Interface  for  Use  on  Metallic  loop* 
for  Application  on  the  Network  Side  of  the  NT  (Layer  1 
Specification),  1992 

TI.601 

Mandated 

(Approved) 

[PC 

ITU-T 

Numbering  Plan  for  the  ISDN  Era,  1991 

E.I64 

Mandated 

(Approved) 

GPC 

DOD 

Syitem  Interface  Criteria  (lection  on  WNDP) 

DCAC  370-175-13 

Mandated 

(Approved) 

[PC 

rru-T 

ISDN  User-Network  Interface  -  Data  Link  Layer 
Specification  •  Digital  Subscriber  Signaling  Syitem  No.  I, 
1993 

Q.921 

Mandated 

(Approved) 

IPC 

ITU-T 

ISDN  User-Network  Interface  Layer  3  Specification  for 
baiic  Call  Control  -  Digital  Subscriber  Signaling  System 
No.  1  (DSS  1),  Network  Layer,  User- Network 
Management,  1989 

Q.931 

Mandated 

(Approved) 

CPC 

IETF 

Multiprotocol  Interconnect  on  X.25  and  ISDN  in  the 
Packet  Mode 

RFC  1356:1992 

Mandated 

(Approved) 

CPC 

IETF 

PPP  over  ISDN 

RFC  1618:1994 

Mandated 

(Approved) 

NPC 

ANSI 

Signaling  System  Number  7  (SS7)  Message  Transfer  Part 
(MTP) 

Tl.lll 

Adopted 

(Approved) 

NPC 

ANSI 

Signaling  System  Number  7  (SS7)  Signaling  Connection 

Control  Part  (SCCP) 

T1.112 

Adopted 

(Approved) 

NPC 

ANSI 

Signaling  System  Number  7  (SS7)  ISDN  User  Part  (1SUP) 

T1.113 

Adopted 

(Approved) 

NPC 

ANSI 

Signaling  System  Number  (SS7)  Transaction  Capabilities 
Application  Part  (TCAP) 

T1.I14 

Adopted 

(Approved) 

NPC 

ANSI 

Basic  Access  Interface  for  S  and  T  Reference  Points  (Layer 
1) 

TI.605 

Adopted 

(Approved) 

NPC 

ANSI 

Digital  Subscriber  Signaling  System  Number  1  (DSSI) 
Signaling  Spec  for  X.25  Packet  Switched  Bearer  Service 

T  1.608 

Adopted 

(Approved) 

NPC 

ANSI 

Interworking  Between  the  ISDN  User-Network  Interface 
Protocol  and  SS7  [SUP 

T  1.609 

opted 

vrtpp  roved) 

IPC 

ITU-T 

Numbering  Plan  for  the  International  Telephone  System 

E.I63 

Adopted 

(Approved) 

GPC 

NIST 

Integrated  Services  Digital  Network  (ISDN) 

FTPS  PUB  182 

Informational 

(Approved) 
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3.7.3.6J  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.3.6  J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  'he  existing  standards. 

3.7.3.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7  J.65  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ANSI  T1.219,  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN) 
Management  -  Overview  and  Principles. 

2.  ANSI  T1.236,  Telecommunications  -  Signaling  System  Number  7  (SS7)  -  ISDN 
User  Part  Compatibility  Testing. 

3.  ANSI  T1.239,  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN) 
Management  -  User-Network  Interface  Protocol  Profile. 

4.  ANSI  T1.604,  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN) 

-  Minimal  Set  of  Bearer  Services  for  the  Basic  Rate  Interface. 

5.  ANSI  T1.603,  Telecommunications  -  Integrated  Services  Digital  Network  (ISDN) 

-  Minimal  Set  of  Bearer  Services  for  the  Primary  Rate  Interface. 

6.  ANSI  TI.234,  Telecommunications  -  Signaling  System  Number  7  (SS7)  MTP 
Levels  2  and  3  Compatibility  lasting. 

3.7 .3.6.6  Recommendations.  The  following  base  standarcs  should  be  used  in  support  of  related 
procurements: 


a.  FIPS  PUB  182  provides  a  basic  overviev/  of  N-ISDN  fun  'slity  and  bearer 
services. 

b.  N-ISDN  standards  applicable  to  the  UNI  interface  are  give>  i  ANSI  Tl. 408, 
T1.601,  and  T1.605  for  the  physical  layer;  ITU-T  Q.921,  for  the  link  layer;  ITU-T 
Q.931,  for  the  network  layer  when  supporting  circuit-switched  connections;  and 
ANSI  T1.608,  for  the  network  layer  when  supporting  packet-switched 
connections. 

c.  N-ISDN  standards  applicable  to  the  node-to-network  signaling  interface  are  given 
in  ANSI  Tl. Ill  toT1.114andT1.609. 
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d.  Address  formats  for  N-ISDN  use  the  numbering  plan  and  format  specified  in  ITU- 
T  E.163  and  E.164.  Defense  switched  networks  will  support  the  worldwide 
numbering  and  dialing  plan  specified  in  DCAC  370-175-13. 

e.  RFCs  1356  and  1618  have  been  categorized  as  JTA  mandatory  standards  when 
using  ISDN  packet-switched  services  to  transmit  IP  packets,  and  when  using  the 
PPP  over  ISDN  switched  circuits  configured  for  clear-channel  services. 
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3.7.3.7  N-ISDN  supplementary  services.  A  network  supplies  supplementary  services  in 
addition  to  its  basic  services.  The  generic  procedures  applicable  to  the  control  of  supplementary 
services  at  the  user-to-network  interface  are  defined  in  ANSI  T1.610. 

3.7J.7.1  Standards.  Base  standards  for  N-ISDN  Supplementary  Services  are  presented  in  table 
3.7-18. 


TABLE  3.7-18  N-ISDN  supplementary  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ANSI 

DSS 1  -  Generic  Procedure*  for  the  Control  of  ISDN 
Supplementary  Services 

T1.610 

Adopted 

(Approved) 

NPC 

ANSI 

ISDN  -  Multi-level  Precedence  and  Preemption  (MLPP) 
Service  Capability 

T1.619 

Adopted 

(Approved) 

NPC 

ANSI 

Conferencing  calling  supplementary  service 

T1.647 

Adopted 

(Approved) 

NPC 

ANSI 

Call  Waiting  Supplementary  Service 

T1.613 

Adopted 

(Approved) 

NPC 

ANSI 

Call  Holding  Supplementary  Service 

TI.616 

Adopted 

(Approved) 

IPC 

ITU-T 

Call  Forwarding  Supplementary  Service* 

1.252 

Adopted 

(Approved) 

NPC 

ANSI 

ISDN  Normal  Supplementary  Service  Call  Transfer 

T1.632 

Adopted 

(Approved) 

IPC 

ITU-T 

Multiparty  Supplementary  Services 

1.254 

Adopted 

(Approved) 

NPC 

ANSI 

ISDN  -  Uier-to-User  Supplementary  Service 

T1.621 

Adopted 

(Approved) 

NPC 

ANSI 

ISDN  -  Calling  Line  Identification  Presentation  and 
Restriction  Supplementary  Service 

T1.625 

Adopted 

(Approved) 

IPC 

ITU-T 

Completion  of  call  to  a  Busy  Subscriber 

1.253.3 

Adopted 

(Approved) 

NPC 

ANSI 

ISDN  -  Message  Waiting  Indicator  Control  and 
Notification  Supplementary  Service  and  Associated 
Switching  and  Signaling  Specification 

T1.622 

Adopted 

(Approved) 

NPC 

ANSI 

Explicit  Call  Transfer 

TI.643 

Adopted 

(Approved) 

NPC 

ANSI 

Call  Part 

T1.653 

Adopted 

(Approved) 

NPC 

ANSI 

Call  Deflection  Supplemenlary  Service 

T1.642 

Adopted 

(Approved) 

3.7.3.7.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.3.7.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 
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3.7.3.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 3.7.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ITU-T  1.250,  Definition  of  Supplementary  Services  -  Integrated  Services  Digital 
Network  (ISDN)  -  General  Structure  and  Service  Capabilities. 

2.  ITU-T  1.251,  Number  Identification  Supplementary  Services  -  Integrated  Services 
Digital  Network  (ISDN)  -  General  Structure  and  Service  Capabilities. 

3.  ITU-T  1.253,  Call  Completion  Supplementary  Services  -  Integrated  Services 
Digital  Network  (ISDN)  -  General  Structure  and  Service  Capabilities. 

4.  ITU-T  1.255,  Community  of  Interest  Supplementary  Services  -  Integrated  Services 
Digital  Network  (ISDN)  -  General  Structure  and  Service  Capabilities. 

5.  ITU-T  1.256,  Charging  Supplementary  Services  -  Integrated  Services  Digital 
Network  (ISDN)  -  General  Structure  and  Service  Capabilities. 

6.  ITU-T  1.258. 1,  Terminal  Portability  (TP)  Supplementary  Service  -  Integrated 
Services  Digital  Network  (ISDN)  Service  Capabilities. 

3.7 .3.7.6  Recommendations.  In  addition  to  basic  services,  users  should  specify  the  required 
supplementary  services.  These  services  are  defined  in  various  ANSI  standards  and  ITU-T 
Recommendations  referenced  in  Table  3.7-18.  The  following  base  standards  should  be  used  in 
support  of  related  procurements: 

a.  Multi-level  Precedence  and  Preemption.  The  Multi-level  Precedence  and 

Preemption  (MLPP)  service  provides  a  prioritized  call-handling  service.  This 
service  has  two  parts:  precedence  and  preemption.  Precedence  involves  assigning 
a  priority  level  to  a  call.  Preemption  involves  the  seizing  of  resources,  which  are  in 
use  by  a  call  of  lower  precedence,  by  a  higher-level  precedence  call  in  the  absence 
of  idle  resources.  The  MLPP  service  is  a  network  provider's  option  applicable  to  a 
domain  of  the  network,  that  is,  all  subscribers,  the  network,  and  access  resources 
that  belong  to  the  domain.  Connections  and  resources  belonging  to  calls  from 
MLPP  subscribers  shall  be  marked  with  a  precedence  level  and  domain  identifier 
and  shall  be  preempted  only  by  calls  of  a  higher  precedence  from  MLPP  users  in 
the  same  domain.  Connections  and  resources  belonging  to  calls  from  non-MLPP 
users  and  users  from  other  MLPP  domains  shall  not  be  preempted.  The  maximum 
precedence  level  of  a  subscriber  will  be  set  by  the  service  provider,  based  on  the 
subscriber's  need.  The  subscriber  may  select  a  precedence  level  up  to  and 
including  the  maximum  subscribed-to  precedence  level  on  a  per-call  basis.  The 
MLPP  service  shall  be  mandatory  in  DoD  networks  (both  fixed  and  deployed)  and 
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shall  comply  with  ANSI  T1.619.  For  calls  to  subscribers  in  existing  deployed 
(tactical)  networks  that  comply  with  Tri-Service  Tactical  Communications  (TRI- 
TAC)  specifications,  the  MLPP  service  shall  comply  with  MIL-STD-188-105. 

b.  Conference  Calling.  This  service  is  defined  in  ANSI  T1 .647. 

c.  Call  Waiting.  The  Call  Waiting  service  permits  a  subscriber  to  be  notified  of  an 
incoming  call  with  an  indication  that  no  interface  information  channel  is  available. 
The  subscriber  then  has  the  choice  of  accepting,  rejecting,  or  ignoring  the  waiting 
call.  This  service  is  defined  in  ANSI  T1.613. 

d.  Call  Hold.  The  Call  Hold  service  allows  a  user  to  interrupt  communications  on  an 
existing  call  and  then  subsequently,  if  desired,  reestablish  communications.  This 
service  is  defined  in  ANSI  T1.616. 

e.  Call  Forwarding.  The  Call  Forwarding  service  allows  a  served  user  to  have  the 
network  send  to  another  number  all  incoming  calls  for  the  served  user's  number. 
This  service  is  defined  in  ITU-T  1.252. 

f.  Normal  Call  Transfer.  The  Normal  Call  Transfer  service  allows  a  user  to  transfer 
an  established  call  to  a  third  party.  This  service  is  defined  in  ANSI  T1.632. 

g.  Multiparty.  The  Conference  Call  service  allows  a  user  to  establish  calls  to  multiple 
parties,  one  at  a  time,  using  normal  call-handling  procedures.  The  parties  may  also 
communicate  among  themselves.  This  service  is  defined  in  ITU-T  1.254,  the 
section  titled  1.254. 1  -  Conference  Calling  Service  Description. 

h.  User-to-User  Signaling.  The  User-to-User  Signaling  service  allows  users  to  send 
and  receive  limited  amounts  of  user-generated  information  to  and  from  mother 
user-network  interface.  This  information  is  passed  transparently  (without  changing 
contents)  through  the  network.  Users  can  transfer  information  during  the 
establishment  and  clearing  phases  of  calls.  The  information  is  transmitted  in  the 
user-user  information  element.  The  user-user  information  element  is  an  optional 
element  of  the  following  Digital  Subscriber  Signaling  System  Number  1  (DSS 1 ) 
types  of  messages:  Alerting,  Connect,  Disconnect,  Progress,  Release,  Release 
Complete,  and  Setup.  This  service  is  defined  in  ANSI  T1.621. 

i.  Calling  Line  Identification  Presentation.  The  Calling  Line  Identification 
Presentation  (CLIP)  service  provides  the  called  party  with  the  calling  line 
identification  at  call  setup  on  all  incoming  calls.  This  service  applies  to  both  basic- 
rate  and  primary  rate  interfaces.  This  service  is  defined  in  ANSI  T1.625. 

j.  Calling  Line  Identification  Restriction.  The  Calling  Line  Identification  Restriction 
(CLIR)  service  notifies  the  network  that  the  Calling  Party  Number  is  not  allowed 
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to  be  presented  to  the  called  party.  This  service  is  defined  in  ANSI  T1.625.  The 
service  applies  to  both  basic  rate  and  primary  rate  interfaces. 

k.  Call  Completion  to  a  Busy  Subscriber.  The  Call  Completion  to  a  Busy  Subscriber 
service  allows  an  authorized  user,  A,  who  encounters  a  busy  destination,  B,  to  be 
notified  when  B  becomes  idle.  The  network  reinitiates  the  call  to  destination  B  if 
user  A  desires.  This  service  is  defined  in  ANSI  Drafts  T1 S 1 . 1/92-253  and 

T1S  1.2/92-323. 

l.  Message  Waiting  Indicator  Control  and  Notification.  The  Message  Waiting 
Indicator  (MWI)  Control  and  Notification  service  is  provided  by  the  network  to  a 
Message  Storage  and  Retrieval  (MSR)  system  provider.  The  MSR  system  may 
request  the  network  to  provide  an  indication  to  one  of  its  client  users  that 
messages  are  waiting  at  the  MSR  system.  This  service  is  defined  in  ANSI  T1 .622. 

m.  Explicit  Call  Transfer.  The  Explicit  Call  Transfer  service  allows  a  service  user  that 
has  two  independent  calls  to  interconnect  the  distant  parties  of  the  two  calls.  The 
served  user  is  thereby  released  from  the  call.  This  service,  which  is  defined  in 
ANSI  T1.643,  applies  to  both  basic  rate  and  primary  rate  interfaces. 

n.  Call  Park.  The  Call  Park  service  allows  a  service  user  to  interrupt  speech  or  voice 
band  data  communications  on  an  existing  call  and  then  reestablish  communications 
from  the  same  or  different  terminal  equipment  within  the  same  Call  Park 
Subscriber  Group.  A  Call  Park  Subscriber  Group  is  designated  by  the  service 
provider,  who  may  optionally  group  together  Call  Park  subscribers  into  a  Call  Park 
Subscriber  Group  to  provide  a  measure  of  security.  Call  Park  is  a  circuit-switched 
voice  service  with  similar  characteristics  of  Call  Hold,  except  for  the  ability  to 
reestablish  communications  from  different  terminal  equipment  This  service,  which 
is  defined  in  ANSI  T1.653,  applies  to  the  basic  rate  interface. 

o.  Call  Deflection.  The  Call  Deflection  service  permits  a  served  user  to  respond  to 
an  offered  call  with  a  request  to  deflect  the  call  to  another  number.  As  a 
subscription  option,  the  subscriber  can  invoke  the  deflection  request  after 
answering  the  call.  In  addition,  the  subscriber  can  limit  the  time  it  takes  for  the 
deflected-to  user  to  answer  the  call.  If  the  deflected-to  user  does  not  answer 
within  a  specified  time  interval,  the  network  stops  the  deflection  attempt  and 
returns  a  failure  indication  to  the  deflecting  user,  if  the  deflecting  user  is  still 
associated  with  the  call.  Unlike  Call  Forwarding,  Call  Deflection  allows  the 
network  to  redirect  a  call  only  after  receipt  of  a  specific  user  request  to  deflect  that 
call.  This  service  is  defined  in  ANSI  T1.642. 
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3.7  .3.8  B-ISDN  and  ATM  services.  B-ISDN  signaling  standards  are  basically  N-ISDN 
standards  enhanced  to  support  higher-speed  networks  that  use  ATM  as  the  underlying  switching 
fabric.  B-ISDN  standards  support  all  of  the  N-ISDN  64-kbps  transmission  services  and  facilitate 
migration  from  N-ISDN  to  B-ISDN,  ATM  is  a  high-speed  switching  technology  that  takes 
advantage  of  low  BER  transmission  facilities  to  accommodate  intelligent  multiplexing  of  voice, 
data,  video,  imagery,  and  composite  input  over  high-speed  trunks.  Note  that  ATM  technology  is 
not  limited  to  support  of  B-ISDN  and  data  rates  that  are  broadband  (rates  higher  than  the  primary 
rate  interface). 

3.7.3.8.1  Standards.  Base  standards  for  B-ISDN  and  ATM  are  presented  in  table  3.7-19. 


TABLE  3.7-19  B-ISDN  and  ATM  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

ATM  Forum 

UNI  Specification  V  3.1,  Uier-Network  Interface, 
September  1994 

AF  UNI  v3.1 

Mandated 

(Approved) 

NPC 

ANSI 

ATM  Adaptation  Layer  for  Constant  Bit  Rate  Serviced 
Functionality  and  Specification!,  1993 

TI.630 

Mandated 

(Approved) 

NPC 

ANSI 

ATM  Adaptation  Layer  Type  5  Common  Part  Functions 
and  Specification*,  1994,  which  adopts  ITU-T  1.363, 
lection  6 

TI.635 

Mandated 

(Approved) 

CPC 

IETF 

Classical  IP  and  Address  Resolution  Protocol  (ARP)  over 
ATM 

RFC  1577:1994 

Mandated 

(Approved) 

NPC 

ANSI 

B1SDN  -  ATM  Layer  Functionality  and  Specification 

T  1.627 

Adopted 

(Approved) 

NPC 

ANSI 

BISDN  -  ATM  Adaptation  Layer  3/4  Common  Part 
Function*  &  Specification 

TI.629 

.  .opted 
(Approved) 

NPC 

ANSI 

BISDN  -  Service  Specific  Connection -Oriented  Protocol 
(SSCOP)  Specification 

TI.637 

Adopted 

(Approved) 

IPC 

ITU-T 

B-ISDN  UNI  -  Physical  Layer  Specification 

1.432 

Adopted 

(Approved) 

IPC 

ITU-T 

Service-Specific  Coordination  Function  (SSCF)  for 
Signaling  at  the  UNI 

Q.2130 

Adopted 

(Approved) 

IPC 

ITU-T 

Scrvice-Spccific  Coordination  Function  (SSCF)  for 
Signaling  at  (he  NNI 

Q.2140 

Adipted 

(Approved) 

IPC 

ITU-T 

BISDN  NNI  Network  Signaling  Requirements 

Q.2761  to  Q.2764 

Adopted 

(Approved) 

IPC 

ITU-T 

BISDN  DSS2  UNI  L-3  Spec  for  Basic  Cali/Connection 
Control 

Q.2931 

Adopted 
(Approved  1 

IPC 

ITU-T 

Point-to-Multipoint  Call  Connection  Control 

Q.2971 

Adopted 

(Approved) 

CPC 

DOD 

Standardized  Profile  for  Asynchronous  Transfer  Mode 

(ATM) 

MIL-STD- 1 88- 1 76 

Adopted 

(Approved) 

CPC 

ATM  Forum 

Private  Network-Network  interface  (PNNI) 

AF  PNNI  v  1.0 

Emerging 

(Approved) 

CPC 

LAN  Emulation 

AF  LANE  v  1.0 

Emerging 

(Approved) 
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3.7.3.8 2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.3.8J  Standards  d<  Jciencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.8.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 .3.8.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ANSI  T1.636,  Telecommunications  -  B-ISDN  Signaling  ATM  Adaptation  Layer  - 
Overview. 

2.  ANSI  T1.638,  Telecommunications  -  B-ISDN  Signaling  ATM  Adaptation  Layer  - 
Service-Specific  Coordination  Function  for  Support  of  Signaling  at  the  User-to- 
Network  Interface. 

3.  ANSI  T1.645,  Telecommunications  -  B-ISDN  Signaling  ATM  Adaptation  Layer  - 
Service-Specific  Coordination  Function  for  Support  of  Signaling  at  the  Network 
Node  Interface. 

4.  ITU-T  1.150,  B-ISDN  Asynchronous  Transfer  Mode  Functional  Characteristics. 

5.  ITU-T  1.31 1  (REV1),  B-ISDN  General  Network  Aspects. 

6.  ITU-T  1.361  (REV  1),  B-ISDN  ATM  Layer  Specification. 

7.  ITU-T  1.363,  B-ISDN  ATM  Adaptation  Layer  (AAL)  Specification  -  Integrated 
Services  Digital  Network  (ISDN)  -  Overall  Network  Aspects  and  Functions. 

8.  ITU-T  1.610  (REV1),  B-ISDN  Operation  and  Maintenance  Principles  and 
Functions. 

3.7.3.8.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  ATM  standards  adopted  for  the  Department  of  Defense  (DoD)  are  given  in  DoD's 
ATM  Standards  Profile,  M1L-STD-188-176.  The  network  access  protocols  to 
connect  user  equipment  to  ATM  switches  are  defined  in  the  ATM  Forum's  User- 
Network  Interface  (UNI)  Specification  v3.1. 

b.  ATM  protocol  layers  consist  of  an  ATM  Adaptation  Layer  (AAL),  the  ATM  layer, 
and  a  physical  layer: 
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( 1 )  The  role  of  AAL  is  to  divide  the  variable-length  data  units  into  48-octet 
units  to  pass  to  the  ATM  layer.  AAL1,  which  supports  constant  bit  rate 
service,  is  specified  in  ANSI  TI  .630.  AAL  3/4  and  AAL5,  which  support 
variable  bit  rate  service,  are  specified  in  ANSI  T1.629  and  T1.635, 
respectively. 

(2)  The  ATM  layer  is  specified  in  ANSI  Tl  .627. 

(3)  Physical-layer  standards  for  different  cable  interfaces  and  rates  are  specified 
in  AF  UNI  v3.1.  Physical  media-independent  functions  are  specified  in 
ITU-T  1.432. 

c.  Signaling  messages  to  support  switched  connections  specified  in  ATM  FORUM 
(AF)  UNI  v3.1  are  based  on  ITU-T  Q.2931  and  Q.2971,  but  the  full  functionality 
of  these  two  standards  is  not  supported.  Signaling  AAL  services  are  specified  in 
ANSI  T1.635,  T1.637,  and  ITU-T  Q.2130. 

d.  RFC-1577  supports  interworking  between  ATM  networks  and  IP  router  networks. 

e.  The  ATM  Forum  is  developing  Private  Network-to-Network  Interface  (PNNI) 
routing  and  signaling  standards  to  support  large,  dynamic,  multivendor  ATM 
networks.  PNNI  routing  will  automatically  disseminate  network  topology  and 
resource  information  to  switches  in  the  network,  enabling  quality-of-service 
sensitive  routing.  Using  this  information,  PNNI  signaling  will  allow  calls  to 
traverse  large,  dynamic  networks. 

f.  Signaling  at  the  NNI  is  specified  by  ITU-T  Q.2761  to  Q.2764.  The  signaling  AAL 
services  are  specified  in  ANSI  T1.635,  T1.637,  and  ITU-T  Q.2140. 

g.  LANs,  such  as  Ethernet,  can  be  emulated  over  ATM  networks,  using  ATM  LAN 
Emulation,  Version  1.0. 
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3.7.3.9  Tactical  networks.  Existing  tactical  networks  were  designed  to  operate  over  noisy  radio 
trunks  having  limited  bandwidth.  For  this  reason,  military  standards  were  developed  for  circuit- 
switch  signaling  methods,  channel  structure,  and  voice  digitization.  Tactical  packet-switch 
networks,  however,  use  commercial  standards  (see  3.7.3.3). 

3.7J.9.1  Standards.  Base  standards  developed  for  TRI-TAC/MSE  are  presented  in  table  3.7-20. 


TABLE  3.7-20  Tactical  network  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Interoperability  and  Performance  Standards  for  Digital 
Signaling  and  Supervision  of  Tactical  Communication! 
Systems 

MIL-STD- 188-256 

Leg*cy 

(Approved) 

GPC 

DOD 

MIL-STD- 188-202 

Ug«cy 

(Approved) 

GPC 

DOD 

Analog-lo-Digita!  Conversion  Techniques  (forCVSD 
Modulation) 

MIL-STD- 188-113 

Legacy 

(Approved) 

3.7.3.9.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.3.9 3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.9.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.9.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1 .  MEL-STD- 1 88-200,  System  Design  and  Engineering  Standards  for  Tactical 
Communications,  6/83. 

2.  FED-STD-1015,  Telecommunications:  Analog  to  Digital  Conversion  of  Voice  by 
2,400  Bits/Second  Linear  Predictive  Coding. 

3.  STANAG  4198,  Parameters  and  Coding  Characteristics  That  must  be  Common  to 
Assure  Interoperability  of  2400  bps  Linear  Predictive  Encoded  Digital  Speech. 

4.  STANAG  4209,  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Standards 
for  Analog  to  Digital  Conversion  of  Speech  Signals. 

3.7.3.9.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  MIL-STD- 188-256  specifies  the  trunk  and  loop  signaling  messages  employed  in 
tactical  networks. 
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b.  MIL-STD- 188-202  specifies  the  multiplex  signal  formats  used  by  tactical  circuit 
switches  and  multiplexers. 

c.  MIL-STD-188-1 13  specifies  the  CVSD  voice-encoding  method  used  in  tactical 
networks. 


April  7,  1997 


3.7-48 


Version  3. 1 


Information  Technology  Standards  Guidance 


Communications  And  Network  Services 


3.7.3.10  Voice  encoding  for  networks.  Networks  must  be  able  to  switch,  rate  adapt,  and 
transcode  different  voice  digitization  algorithms,  as  necessary,  to  meet  interoperability 
requirements. 

3.7.3.10.1  Standards.  Base  standards  for  voice  encoding  are  presented  in  table  3.7-21 . 


TABLE  3.7-21  Voice  encoding  standards  for  networks 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-T 

Pulae  Code  Modulation  (PCM)  of  voice  foqoenciea 
(narrowband) 

G.7 1':  1989 

Adopted 

(Approved) 

GPC 

NCS 

Linear  Predictive  Coding  (LPC) 

FED-STD-I015 

Adopted 

(Approved) 

GPC 

NCS 

Analog-lo- -Digital  Conversion  of  R*ko  Voice  by  4800>bf» 
Code  Excited  Linear  Prediction  (CELPO 

FED-STD-1016 

Adopted 

(Approved) 

IPC 

TU-T 

32  kbiU/i  Adaptive  Differential  Pulae  Code  Modulation 
(ADPCM)  •  General  AapecU  of  Digital  Tranamiarion 
Syatema 

G.721 : 1989 

Adopted 

(Approved) 

GPC 

DOD 

Analog- to- Digital  Convent  on  Technique*  (for  CVSD 
Modulation) 

MILSTD-I88.il  3 

Legacy 

(Approved) 

3.7.3.10.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.3. 10  J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.10.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.10.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1 .  ITU-T  G.7 1 2,  Performance  Characteristics  of  PCM  Channels  Between  4-wire 
Interfaces  at  Voice  Frequencies  -  General  Aspects  of  Digital  Transmission 
Systems;  Terminal  Equipment 

2.  ITU-T  G.7 1 3,  Performance  Characteristics  of  PCM  Channels  Between  2-wire 
Interfaces  at  Voice  Frequencies  -  General  Aspects  of  Digital  Transmission 
Systems;  Terminal  Equipment  (Replaced  by  Recomm.  G.7 12). 

3.  STANAG  4198,  Parameters  and  Coding  Characteristics  That  must  be  Common  to 
Assure  Interoperability  of  2400  bps  Linear  Predictive  Encoded  Digital  Speech. 

4.  STANAG  4209,  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Standards 
for  Analog  to  Digital  Conversion  of  Speech  Signals. 
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3.7.3. 10.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

a.  ITU-T  G.7 1 1  specifies  the  64-lcbps  voice-encoding  method  used  in  commercial 
and  strategic  networks. 

b.  MIL-STD-*e8-113  specifies  the  16/32-kbps  voice-encoding  method  used  in 
tactical  networks. 

c.  FED-STD-1015  specifies  the  2400-bps  voice-encoding  method  used  in  STU-IIls. 

d.  FED-STD- 1016  specifies  the  4800-bps  voice-encoding  method  used  in  STU-IDs. 

e.  ITU-T  G.721  specifies  the  32-kbps  voice-encoding  method  used  to  double  the 
channel  capacity  of  high-cost  T- 1  transmission  facilities. 
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3.7.3.11  Timing  and  synchronization.  In  general,  bit  timing  for  hosts  and  end  systems  will  be 
slaved  to  the  local  network. 

3.7.3.11.1  Standards.  Base  standards  for  timing  and  synchronization  are  presented  in 
table  3.7-22. 


TABLE  3.7-22  Timing  and  synchronization  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mill 

NPC 

ANSI 

Synchronization  Interface  Standards  for  Digital  Service 

T1.I01 

Adopted 

(Approved) 

GPC 

NCS 

Tkne  and  Frequency  Reference  Information  in 
Telecommunications  Syilemi 

FED-STD-1002 

Adopted 

(Approved) 

GPC 

DOD 

Standard*  for  Communications  Timing  and 
Synchronization  Subsystems 

MIL-STD- 188-1  IS 

Ug«cy 

(Approved) 

3.7.3.11.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.3. 11J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.11.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.11.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

ITU-T  G.810,  Considerations  on  Timing  and  Synchronization  Issues  -  Digital  Networks, 
Digital  Sections  and  Digital  Line  Systems. 

3.7.3.11.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  Systems  that  require  time  and  frequency  reference  information  based  on 
coordinated  universal  time  (UTC)  will  comply  with  FED-STD-1002. 

b.  Local-network  and  wide-network  elements  provide  stratum-1  clock  accuracy,  as 
defined  in  ANSI  T1.101,  and  buffering  sufficient  to  maintain  bit  count  integrity 
(BCI)  for  a  minimum  of  24  hours. 

c.  Systems  that  use  bit-timing  slaved  to  the  network  will  comply  with  MIL-STD- 1 88- 
115. 
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3.7.3.12  Network  management.  Network  management  includes  the  capability  to  control  the 
network's  topology,  dynamically  segment  the  network  into  multiple  logical  domains,  maintain 
network  routing  tables,  monitor  the  network  load,  and  make  routing  adjustments  to  optimize 
throughput  Network  management  also  provides  the  capability  to  review  and  publish  addresses  of 
network  objects;  monitor  the  status  of  network  objects;  start,  restart,  reconfigure,  or  terminate 
network  objects;  and  detect  loss  of  network  objects  to  support  automated  fault  recovery. 

3.7  J.12.1  Standards.  Base  standards  for  network  management  are  presented  in  table  3.7-23. 


T^ABLE^;7^3_Net2Wk_managernent_standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Litecycle) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Adopted 

(Approved) 

IPC 

ISO/DEC 

OS I  Common  Management  Information  Services  (CMIS) 
Definition,  with  Amendment  4:  Acceaa  Control 

9595:1991/ 

AM4:1992 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  •  Open  Sytlemi  Interconnection  • 
Common  Management  Information  Protocol  (CMIP)  -  Put 

1:  Specification  (Include*  amendment  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Adopted 

(Approved) 

3.7.3.12.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.3.12.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.3.12.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.3.12.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ISO  7498-4,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Reference  Model  -  Part  4:  Management  Framework,  First  Edition. 

2.  ISO  10165-1,  Information  Technology  -  Open  Systems  Interconnection  -  Structure 
of  Management  Information  -  Part  1 :  Management  Information  Model,  First 
Edition. 

3.  ISO  10165-2,  Information  Technology  -  Open  Systems  Interconnection  -  Structure 
of  Management  Information  -  Part  2:  Definition  of  Management  Information,  First 
Edition. 

4.  ISO  10165-4,  Information  Technology  -  Open  Systems  Interconnection  -  Structure 
of  Management  Information  -  Part  4:  Guidelines  for  the  Definition  of  Managed 
Objects,  First  Edition. 
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5.  ISO  DIS  10165-7,  Information  Technology  -  Open  Systems  Interconnection  - 
Structure  of  Management  Information  -  Part  7:  General  Relationship  Model, 

3.7 -3.12.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

DISN  network  management  communications  protocol  and  services,  which  provide  the 
management  information-transfer  mechanism,  are  specified  in  FIPS-PUB-179,  the  sections  titled 
Common  Management  Information  Protocol  (CMIP)  and  Common  Management  Information 
Services  (CMIS).  A  complete  coverage  of  CMIP  and  CMIS  can  be  found  in  ISO  9596-1  and  ISO 
9595,  respectively. 
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3.7.4  Interworking  services.  Interworking  standards  are  required  to  ensure  interoperability 
between  differing  networks.  Interworking  requires  transformation  and  compatibility  at  the  lower 
three  layers. 

3.7.4. 1  Interworking  services.  (See  the  Interworking  MLS  A,  above.) 

3.7.4.1.1  Standards.  Base  standards  for  interworking  are  presented  in  table  3.7-24. 


TABLE  3.7-24  Interworking  standards 


1  Standard 
Type 

Sponsor 

Standard 

Standard 

Reference 

HmK 

CPC 

IETF 

aauical  IP  and  Address  Resolution  Protocol  (ARP)  over 
ATM 

RFC  1577:1994 

Mandated 

(Approved) 

[PC 

IAB 

Standard  for  the  Transmission  of  IP  Datagrams  Over 
Ethernet  Networks 

Standard  4 1/RFC- 
894 

Mandated 

(Approved) 

[PC 

IAB 

Transmission  of  IP  and  ARP  over  FDDI  Networks 

Standard  36/RFC- 
1390 

Adopted 

(Approved) 

IPC 

IAB 

Transmission  of  IP  Datagrams  over  IF.EE  802  Networks 

Standard  43/RFC- 
1042 

Adopted 

(Approved) 

CPC 

IETF 

Multiprotocol  Interconnect  on  X.25  and  ISDN  in  the 
Padcet  Mode 

RFC  1356:1992 

Adopted 

(Approved) 

NPC 

ANSI 

DSS1  Signaling  Specification  for  Frame  Relay  Bearer 
Service 

T1.617 

Adopted 

(Approved) 

NPC 

ANSI 

Core  Aspects  of  Frame  Protocol  for  Use  with  Frame  Relay 
Bearer  Service 

T1.618 

Adopted 

(Approved) 

NPC 

ANSI 

Frame  Relaying  Bearer  Service  Interworking 

T1.633 

Adopted 

(Approved) 

NPC 

ANSI 

Frame  Relaying  Service  Specific  Convergence  Sublayer 
(FR-SSCS) 

T1.634 

Adopted 

(Approved) 

IPC 

ITU-T 

Interworking  between  Signaling  System  No.  7  Broadband 
ISDN  User  Part  (BISUP)  and  Narrowband  ISDN  User  Part 
(N1SUP) 

Q.2660 

Adopted 

(Approved) 

CPC 

Frame  Relay 
Forum 

Frame  Relay/ATM  PVC  Network  Interworking 
Implementation  Agreement 

FRF.5 

Adopted 

(Approved) 

CPC 

Frame  Relay 
Forum 

Frame  Relay/ATM  PVC  Service  Interworking 
Implementation  Agreement 

FRF.8 

Adopted 

(Approved) 

CPC 

SMDS  Interest 
Group 

■B HsBHlH 

SlG-TWG-008 

Adopted 

(Approved) 

3.7.4.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.4.1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 


3.7.4.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 
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3.7 .4.1.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ANSI  T1.609,  Telecommunications  -  Interworking  Between  the  ISDN  User- 
Network  Interface  Protocol  and  the  Signaling  System  Number  7  ISDN  User  Part. 

2.  ANSI  T1.656,  Telecommunications  -  Broadband  ISDN  -  Interworking  Between 
Signaling  System  Number  7  Broadband  (B-ISUP)  and  ISDN  User  Part  (ISUP). 

3.  ITU-T  Q.608,  Miscellaneous  Interworking  Aspects  -  Interworking  of  Signaling 
Systems. 

3.7.4. 1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  IP  level  interworking  between  different  LANs  is  specified  in  LAB-STD-36,  -41, 
and  -43.  IP  interworking  over  ATM  is  specified  in  RFC  1577. 

b.  RFC  1356  specifies  the  method  of  interworking  IP  with  X.25. 

c.  For  frame  relay  interworking  with  N-ISDN,  ANSI  T1.617  specifies  access 
connections  on  demand,  and  ANSI  T1.618  specifies  the  method  for  multiplexing 
multiple  subscriber  data  streams  onto  a  single  connection.  Frame  relay 
interworking  with  B-ISDN  is  specified  in  ANSI  T1.633  and  T1.634.  FRF.5 
specifies  interworking  between  frame  relay  and  ATM;  FRF.8  specifies  the 
interworking  of  a  frame-relay-service  user  and  an  ATM  service  user. 

d.  Interworking  between  N-ISDN  and  B-ISDN  is  specified  in  ITU-T  Q.2660. 

e.  Interworking  between  SMDS  and  ATM  is  specified  in  SIG-TWG-008. 
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3.7.5  Personal  communications  services.  Personal  communications  services  (PCS)  will  support 
both  terminal  mobility  and  personal  mobility.  Personal  mobility  allows  users  to  gain  access  to 
telecommunication  services  from  any  convenient  terminal  with  which  they  choose  to  associate 
themselves.  Personal  mobility  may  be  provided  by  either  wireline  or  wireless  terminals.  Terminal 
mobility  is  based  on  wireless  access.  Thus,  wireless  access  standards  will  govern  the  protocols  and 
procedures  for  establishing  connections  among  mobile  terminals  and  between  them  and  fixed 
terminals  of  a  switched  network  (or  mobile  terminals  of  a  different  cellular  system). 

3.7.5.1  Wireless  access.  Cellular  mobile  systems  use  wireless  access  standards  to  support 
terminal  mobility.  Wireless  access  allows  subscribers  to  place  and  receive  telephone  calls  over 
fixed  networks  wherever  cellular  service  is  provided.  Two  methods  for  digital  access  have 
emerged,  time-division  multiple  access  (TDMA)  and  code-division  multiple  access  (CDMA).  In 
North  America  the  standards  for  TDMA  and  CDMA  are  based  on  IS- 136  and  IS-95-A, 
respectively.  Both  of  these  standards  use  IS-41-C  as  the  standard  signaling  protocol. 

3.7.5. 1.1  Standards.  Table  3.7-25  presents  base  standards  used  in  support  of  cellular  mobile  and 
PCS  systems. 


TABLE  3.7-25  Current  wireless  access  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

EIA/TIA 

800  MHz  TDMA  Cellular  -  Radio  Interface  -  Mobile 
Station  -  Baae  Station  Compatibility  Standard 

IS- 136 

Adopted 

(Approved) 

NPC 

ANSI 

Pervn.d  Station-Base  Statical  Compatibility  Requirement 
fo  r  1 .8  to  2.0  GHz  CDMA  Personal  Communication* 
System* 

J -STD-008 

Adopted 

(Approved) 

NPC 

ANSI 

IS- 136  Based  Mobile  Station  Minimum  Performance  1900 
Mhz  Standard 

J -STD-009 

Adopted 

(Approved) 

NPC 

ANSI 

IS  •  1 36  Based  Base  Station  Minimum  Performance  1 900 
Mhz  Standard 

J-STD-010 

Adopted 

(Approved) 

NPC 

ANSI 

IS- 136  Based  Air  Interface  Compatibility  1900  Mhz 
Standard 

J-STD-01 1 

Adopted 

(Approved) 

CPC 

EIA/TIA 

Cellular  Radio  Telecommunications  Intersystems 
Operations 

IS-41-C 

Emerging 

(Approved) 

CPC 

EIA/TIA 

Cellular  System  Dual-Mode  Mobile  Station  Base  Station 
Compatibility  Standard. 

IS-54-B 

Emerging 

(Approved) 

CPC 

EIA/TIA 

Mobile  Station-Base  Station  Compatibility  Standard  for 
Dual-Mode  Wideband  Spread-Spectrum  Cellular  Systems 

IS-95-A 

Emerging 

(Approved) 

3.7.5.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.5.1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.5.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 
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3.7.5.1.5  Related  standards.  Related  standards  arc  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  EIA  TSB47  1S-54,  Implementation  Issues. 

2.  EIA  TSB5 1 ,  Cellular  Radiotelecommunications  Intersystem  Operations: 
Authentication,  Signaling  Message  Encryption  and  Voice  Privacy. 

3.  EIA  TSB56-A,  Cellular  Application  Level  Testing  for  iS-41  Revision  B,  TSB51 
and  IS-53. 

4.  EIA  TSB64 IS-41-B,  Support  for  Dual-Mode  Wideband  Spread  Spectrum  Mobile 
Stations. 

5.  EIA  TLA/IS-98,  Recommended  Minimum  Performance  Standards  for  Dual-Mode 
Wideband  Spread  Spectrum  Cellular  Mobile  Stations. 

3.7 .5.1.6  Recommendations.  PCS  is  an  emerging  technology  with  the  two  predominant 
competing  world-wide  methodologies:  code-division  multiple  access  (CDMA)  and  time-division 
multiple  access  (TDMA).  Of  these,  CDMA  offers  the  best  technical  advantages  for  military 
applications  based  on  its  use  of  Direct  Sequence  Spread  Spectrum  (DSSS)  techniques  which 
provide  increased  channel  capacity,  low  probability  of  intercept  (LPI),  and  protection  against 
jamming.  The  PCS  air-interface  standard  for  CDMA  is  J-STD-008  which  is  a  frequency 
upshifted  version  of  IS-95-A,  the  800  MHz  digital  cellular  standard  fer  CDMA.  The  PCS  air- 
interface  standard  for  TDM  A  is  IS- 1 36  which  is  a  frequency  upshifted  version  of  IS-54B,  the  800 
MHz  digital  cellular  standard  for  TDMA.  In  North  America,  the  standard  signaling  protocol  for 
CDMA  and  TDMA  mobile  cellular  is  IS-41 -C.  It  should  be  recognized  that  for  Operations- 
Other-Than-War  (OOTW),  a  user  may  have  to  support  multiple  protocols  to  access  region- 
specific  international  digital  PCS/'mobile  cellular  infrastructures. 
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3.7.5.2  Future  public  land  mobile  telecommunications  systems.  ITU  is  now  working  on 
standards  for  future  public  land  mobile  telecommunications  systems  (FPLMTS)  standards.  The 
aim  of  this  effort  is  to  achieve  better  compatibility  among  various  cellular  systems  so  that 
universal  global  access  supporting  terminal  mobility  will  become  a  reality. 

3.7.5  J.l  Standards.  The  documents  shown  in  table  3.7-26  provide  guidance  for  future 
implementation  of  land  mobile  telecommunications  systems. 


mm 


TABLE  3.7-26  FPLMTS  standards 


Standard 

Type 


Standard 


Sponsor 


Standard 

Reference 


Coding  of  Speech  >t  16  kbki/i  ming  Low- Delay  Code 


Adopted 


(Approved) 
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3.7 .5.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7 .5.2.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.5.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.5.2 £  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1 .  ITU-T  E.  173,  Routing  Plan  for  Interconnection  Between  Public  Land  Mobile 
Networks  and  Fixed  Terminal  Networks. 

2.  ITU-T  E.201,  Reference  Recommendation  for  Mobile  Services. 

3.  ITU-T  E.202,  Network  Operational  Principles  for  Future  Public  Mobile  Systems 

and  Services. 

4.  ITU-T  E.212,  Identification  Plan  for  Land  Mobile  Stations  -  Telephone  Network 
and  ISDN  -  Operation,  Numbering,  Routing  and  Mobile  Service. 

5.  ITU-T  E.220,  Interconnection  of  Public  Land  Mobile  Networks. 

6.  ITU-T  F.l  15,  Service  Objectives  and  Principles  for  Future  Public  Land  Mobile 

Telecommunication  Systems  -  Operations  and  Quality  of  Service  -  Mobile  Service. 

7.  ITU-T  Q.  100 1 ,  General  Aspects  of  Public  Land  Mobile  Networks  -  Public  Land 
Mobile  Network  Interworking  with  ISDN  and  PSTN. 

3.7.5.2.6  Recommendations.  Future  Public  Land  Mobile  Telecommunication  Systems  is  an 
emerging  technology.  For  additional  guidance,  users  should  review  ITU-T  F.l  15,  Service 
Objectives  and  Principles  for  Future  Public  Land  Mobile  Telecommunication  Systems  - 
Operations  and  Quality  of  Service  -  Mobile  Service. 


April  7,  1997 


3.7-59 


Version  3. 1 


Information  Technology  Standards  Guidance 


Communications  And  Network  Services 


3.7.5 3  Universal  personal  communications.  Universal  personal  telecommunications  (UPT) 
allows  users  to  gain  access  to  a  variety  of  authorized  services  without  limiting  personal  mobility, 
terminal  mobility,  or  both.  All  authorized  services  will  be  available  to  the  user,  irrespective  of 
location  and  limited  only  by  the  capabilities  of  the  terminal  and  the  network  used. 

3.7.5  J.l  Standards.  ITU  Recommendations  (approved  or  in  draft)  are  listed  in  table  3.7-27. 


TABLE  3.7-27  Universal  personal  communications  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IK’ 

ITU-T 

UPT  Service  Set  1 

P.85I 

Adopted 

(Approved) 

tPC 

ITU-T 

UPT  Numbering 

E.  168 

Adopted 

(Approved) 

tPC 

ITU-T 

UPT  Cnde-of-Service  Concept 

E.775 

Infonnetionel 

(Approved) 

f.  . 
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3.7.5.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.5.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.5.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 .5.3.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ITU-T  E.175,  Routing  Principles  and  Guidance  for  Universal  Personal 
Telecommunications  (UPT)  -  Telephone  Network  and  ISDN  -  Operation, 
Numbering,  Routing  and  Mobile  Service. 

2.  ITU-T  F.850,  Principles  of  Universal  Personal  Telecommunication  (UPT)  - 
Operations  and  Quality  of  Service, 
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3.  ITU-T  Q.76,  Service  Procedures  for  Universal  Personal  Telecommunication  - 
Functional  Modeling  and  Information  Flows  -  General  Recommendations  on 
Telephone  Switching  and  Signaling  -  Functions  and  Information  Flows  for 
Services  in  the  ISDN. 

3.7.S.3.6  Recommendations.  Universal  Personal  Telecommunications  is  a  new  service  concept 
and  it  is  not  totally  defined.  For  more  information  users  should  review  ITU-T  F.850,  Principles  of 
Universal  Personal  Telecommunication  (UPT)  -  Operations  and  Quality  of  Service. 
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3.7.6  Transmission  media.  Transmission  media  of  interest  to  DoD  communications  systems 
includes  satellite  terrestrial  radio  and  fiber  and  metallic  cable.  Also  included  in  this  section  are 
standards  for  multiplexer  formats  and  message  formats  for  tactical  digital  information  links 
(TADIL). 

3.7.6.1  Military  satellite  communications.  The  standards  for  military  satellite  communications 
(M1LSATCOM)  can  be  categorized  in  accordance  with  the  frequency  band  of  operation,  that  is, 
ultra  high  frequency  (UHF),  super  high  frequency  (SHF),  and  extremely  high  frequency  (EHF). 

3.7.6.1.1  Standards.  Base  standards  for  MILSATCOM  are  presented  in  table  3.7-28. 


TABLE  3.7-28  Military  satellite  communications  standards 


Stan  lard 
Type 

Sponsor 

Standard 

Standard 

Reference 

Sta-  -  s 
DoD 

(Lifecycle) 

GPC 

DOD 

MIL-STD-188-181 

Mandated 

(Approved) 

GPC 

DOD 

MIL-STD-188-182 

Mandated 

(Approved) 

GI*C 

DOD 

Interoperability  Standard  for  23kHz  UHF/TDMA/DAMA 
Terminal  Waveform,  September  18, 1992 

MDL.-STD-188-I83 

Mandated 

(Approved) 

GPC 

DOD 

Interoperability  and  Performance  Standard  for  the  Data 
Control  Wavefoim,  August  20, 1993 

MIL-STD-188-184 

Mandated 

(Approved) 

GPC 

DOD 

MIL- STD- 188- 164 

Mandated 

(Approved) 

GPC 

DOD 

SHF  Interoperability  and  Performance  Standard*  for  SHF 
Satellite  Communication!  PSK  Modem*  (Frequency 
Division  Multiple  Acce*t  (FDMA)  Operation*),  January 

13.  1995 

MIL-STD-188-165 

Mandated 

(Approved) 

GPC 

DOD 

EHF  LDR  uplink*  and  Downlinks,  December  10, 1992 

MIL-STD-1582 

Mandated 

(Approved) 

GPC 

DOD 

EHF  MDR  Uplink*  and  Downlinks,  August  26. 1993 

MIL-STD-188-136 

Mandated 

(Approved) 

GPC 

DOD 

Interoperability  of  UHF  MILSATCOM  DAMA  Control 
System 

MIL-STD-188-185 

Emerging 

(Approved) 

IBS 

»> v>rv,/y--  "jlggS* 
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3.7.6. 1.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.6.1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.6.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 
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3.7.6.1  J  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Nonnative  references  are  included  in  the  base  standards. 

1.  Intelsat  Earth  Station  Standard  (IESS)  308,  Performance  Characteristics  for 
Intermediate  Data  Rate  (IDR)  Digital  Carriers  (Standard  A,  B,  C,  E,  and  F  Earth 
Stations). 

2.  IESS  309,  QPSK/FDMA  Performance  Characteristics  of  INTELSAT  Business 
Services  (IBS). 

3.7.6. 1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  UHF  SATCOM  Standards: 

( 1 )  The  parameters  defined  in  MIL-STD- 188-181  provide  for  the 
interoperability  and  performance  of  UHF  SATCOM  terminals  that  use 
nonprocessed  5-kHz  (natTOwband)  and  25-kHz  (wideband)  channels.  The 
dedicated/phase-shift  keying  (PSK)  mode  is  used  for  narrowband  channels. 
The  dedicated/  frequency-shift  keying  (FSK)  mods,  or  optional  PSK 
modes,  are  used  for  wideband  channels. 

(2)  The  parameters  defined  in  MEL-STD- 188-182  provide  for  the  dynamic 
sharing  of  one  or  more  nonprocessed  narrowband  (5-kHz)  UHF  SATCOM 
channels  i.i  demand-assignment  multiple  access  (DAMA)  mode. 

(3)  The  parameters  defined  in  MIL-STD-188-183  provide  for  the  dynamic 
sharing  of  a  nonprocessed  wideband  (25-kHz)  UHF  SATCOM  channel  in 
the  TDMA/DAMA  mode. 

(4)  The  parameters  defined  in  MIL-STD- 188-184  provide  for  data 
compression  and  adaptive  error-correction  processing  of  user  data. 

(5)  The  parameters  defined  in  MIL-STD- 1 88- 1 85  will  provide  for  centralized 
control  and  decentralized  management  of  5-kHz  and  25-kHz  UHF  military 
satellite  communications  (MILSATCOM)  resources. 

b.  SHF  SATCOM  Standards: 

(1)  MIL-STD-188-164  defines  minimum  mandatory  rf  and  IF  requirements  to 

ensure  interoperability  of  SATCOM  earth  terminals  operating  over  C-band, 
X-band,  and  Ku-band  channels. 
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(2)  MIL-STD- 188-165  defines  minimum  mandatory  requirements  to  ensure 
interoperability  of  PSK  modems  operating  in  the  FDMA  mode  with  SHF 
SATCOM  earth  terminals. 

(3)  MIL-STD- 1 88- 166  will  define  the  communications  link  characteristics 
required  to  control  and  manage  access  to  SHF  SATCOM  transponders. 

(4)  MIL-STD-188-167  will  define  the  communications  protocols  required  for 
assignment  of  SHF  satellite  space  resources  in  accordance  with  demand. 

(5)  MIL-STD- 188- 168  will  define  the  formats,  protocols,  and  other 
communications  techniques  required  for  transferring  multiple-user 
information  over  a  single  SATCOM  link. 

c.  EHF  SATCOM  Standards: 

(1)  MIL-STD-1582  defines  a  common  waveform  for  low-data-rate  (75  to 
2400  bps)  EHF  satellite  data  links. 

(2)  MIL-STD- 188- 136  defines  a  common  waveform  for  medium-data-rate  (4.8 
kbps  to  1.544  Mbps)  EHF  satellite  data  links. 
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3.7.6.2  Radio  communications.  Radio  communications  standards  cover  the  frequency  range 
from  low  frequencies  (LF)  to  ultra  high  frequencies  (UHF).  They  provide  service  to  fixed  and 
mobile  applications. 

3.7.6 2.1  Standards.  Base  standards  for  radio  communications  are  presented  in  table  3.7-29. 


TABLE  3.7-29  Radio  communications  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Medium  Mid  High  Frequency  Radio  Equipment  Standard, 
September  10. 1993 

MIL- STD-188- 
141  A 

Mandated 

(Approved) 

GPC 

DOD 

Interoperability  Standard  Anti-Jam  Communications  (2-30 
Mb?) 

MIL-STD-188- 

148A 

Mandated 

(Approved) 

GPC 

DOD 

Data  Modems,  Interoperability  and  Performance  Standards, 
September  30.  1991 

MIL-STD- 188- 
UOA 

Mandated 

(Approved) 

GPC 

DOD 

Tactical  Single  Channel  (VHF)  Radio  Equipment,  June  20, 
1983 

MIL-STD- 188-242 

Mandated 

(Approved) 

GPC 

DOD 

Tactical  Single  Channel  (UHF)  Radio  Communications. 
March  15. 1989 

MIL-STD- 188-243 

Mandated 

(Approved) 

GPC 

DOD 

Digital  Line-of-Sight  (LOS)  Microwave  Radio  Equipment, 
July  28. 1992 

MIL-STD- 188- 145 

Mandated 

(Approved) 

GPC 

DOD 

Equipment  Technical  Design  Standards  for  Common  Long 
Haul/Tactical  Radio  Communications  in  the  LF  and  Lower 
Frequency  Bands 

MIL-STD- 188- 
140A 

Legacy 

(Approved) 

GPC 

NCS 

Interoperability  Requirements  for  Meteor  Burst  Radio 
Communications  Between  Conventional  Master  and 
Remote  Stations 

FED-STD-IOSS 

Leg«y 

(Approved) 

GPC 

NCS 

FED-STD- 1056 

Legacy 

(Approved) 

GPC 

NCS 

Interoperability  Requirements  for  Meteor  Burst  Radio 
Communications  Between  Networks  by  Mister  Stations 

FED-STD- 1057 

Legacy  I! 

(Approved) 

GPC 

DOD 

JIEO  Spec  9001 

Ug«y 

(Approved) 

pf"» 

‘ 

p  ^  _  p 
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3J.6.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.6.2.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.6.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.6.2.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 
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1.  MIL-STD- 188-200,  System  Design  and  Engineering  Standards  Tactical 
Communication. 

2.  MIL-STD-449,  Radio  Frequency  Spectrum  Characteristics,  Measurement  of. 

3.  MIL-STD- 46 1 ,  Electromagnetic  Interface  Characteristics,  Requirements  for 
Equipment 

4.  MIL-STD-462,  Electromagnetic  Interface  Characteristics,  Measurements  of. 

5.  MIL-STD-463,  Definition  and  System  of  Units,  Electromagnetic  Interface  and 
Electromagnetic  Compatibility  Technology. 

6.  STANAG  4204,  Technical  Standards  for  Single  Channel  VHF  Radio  Equipment 

3.7.6.2.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  LF  radio  communications  standards:  Parameters  for  radio  subsystems  operating  in 
the  low  frequency  (LF)  and  lower  bands  are  defined  in  MIL-STD-188-140A. 

b.  MF  and  HF  radio  communications  standards:  Parameters  for  radio  subsystems 
operating  in  the  medium  frequency  (MF)  and  high  frequency  (HF)  bands  are 
defined  in  MIL-STD- 188- 141  A.  Standards  for  HF  radio  automatic  link 
establishment  (ALE)  and  HF  automatic  operation  in  stressed  environments  are 
provided  in  MIL-STD-188-141A. 

c.  HF  radio  communications  standards:  Parameters  for  HF  radio  anti-jam  (AJ) 
transmission  systems  are  defined  in  MIL-STD- 188- 148A  and  MIL-STD- 188- 

1 10A.  Emerging  standards  for  HF  store-and-forward  service  and  for  automatic 
HF  networking  to  multiple  transmission  media  will  be  in  FED-STD-1047  and 
FED-STD-1048,  respectively. 

d.  Meteor  burst  radio  communications  standards:  Meteor  burst  radio 
communications  relies  on  the  billions  of  meteors  that  enter  the  earth's  atmosphere 
daily,  are  vaporized  by  atmospheric  friction,  and  produce  ionized  trails.  A  high 
percentage  of  these  trails  lasts  less  than  one-half  second,  although  some  trails  last 
up  to  several  seconds.  Trail  occurrence  and  duration  are  random  events.  FED- 
STD-1055,  FED-STD-1056,  and  FED-STD-1057  are  intended  for  use  by  systems 
that  use  meteor  burst  communications. 

e.  VHF  radio  communications  standards:  Parameters  for  radio  subsystems  using 
frequencies  between  30  and  300  MHz  are  defined  in  MIL-STD- 188-242. 
Parameters  for  VHF  radios  requiring  transmission  security  are  defined  in  Joint 
Interoperability  and  Engineering  Organization  (JIEO)  Specification  9001. 
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f.  UHF  radio  communications  standards:  Parameters  for  radio  subsystems  using 
frequencies  between  300  and  3000  MHz  are  defined  in  MIL-STD- 188-243. 
Parameters  for  UHF  radios  requiring  transmission  security  are  defined  in 
Standardization  Agreement  (STANAG)  4372. 

g.  SHF  radio  subsystems:  Parameters  for  radio  subsystems  using  frequencies 
between  3  and  30  GHz  are  defined  in  MIL-STD-188-145. 
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3.7.6 3  Cable  interfaces.  Cable  interfaces  apply  to  terminal  access  and  user-to-network 
interfaces  (UNI).  They  also  apply  within  networks  for  trunking  between  switches. 

3.7.6 3.1  Standards.  Base  standards  for  cable  interfaces  are  presented  in  table  3.7-30. 


TABLE  3.7-30  Cable  interfaces  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

NPC 

ANSI 

Digital  Hierarchy  -  Optical  Interface  Specification* 
(SONET)  (Single  Mode  •  Short  Reach),  1991 

Tl.l 17 

Mandated 

(Approved) 

[PC 

ITU-T 

RiysicalTilectrical  Characteristic*  of  Hierarchical  Digital 
Interface*  (For  E-i) 

G.703 

Informational 

(Approved) 

CPC 

ATM  Forum 

AF-PHY-0015.00 

Informational 

(Approved) 

CPC 

ATM  Forum 

DS-1  Physical  Layer  Specification 

AF-PHY-0016.00 

Informational 

(Approved) 

CPC 

ATM  Forum 

AF-PHY-0018.00 

Informational 

(Approved) 

NPC 

ANSI 

Digital  Hierarchy  •  Optical  Interface  Specifications  (Single 
Mode) 

TI.  106 

Informational 

(Approved) 

GPC 

DOD 

Joint  Interopsiability  via  Fiber  Optic  Cable 

JIEO  Spec  9109 

Legacy 

(Approved) 

GPC 

DOD 

Subsystem  Design  and  Engineering  Standards  for  Common 
Long  Haul/Tactical  Cable  and  Wireless  Communications 

MIL-STD- 188-1 12 

Legacy 

(Approved) 

GPC 

DOD 

System  Design  and  Engineering  Standard*  for  Tactical 
Communications  (Conditioned  Diphase) 

MIL-STD- 188-200 

Legacy 

(Approved) 

3.7.6.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.6.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.6.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.6.3.5  Related  standards.  No  related  standards  have  been  identified. 

3.7.6.3.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  AF-PHY-00 15.00,  AF-PHY-0016,00,  and  AF-PHY-0018.00  are  the  ATM 
Forum's  physical-layer  base  standards  that  apply  to  the  UNI. 

b.  ANSI  T1.106,  ANSI  Tl.l  17,  and  1TU-TG.703  standards  apply  to  optical  and 
metallic  cables  used  for  trunking  applications. 
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c.  Joint  Interoperability  and  Engineering  Organization  (JIEO)  Spec  9109,  MIL- 
STD-188-1 12,  and  MIL-STD- 188-200  apply  to  access,  to  the  UNI,  and  to 
trunking  for  tactical  cable  interfaces. 
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3.7.6.4  Multiplex  format  Where  necessary,  support  of  various  low  transmission  rates  across  a 
high-rate  connection  is  accomplished  through  the  employment  of  synchronous  multiplexing. 

3. 7.6 .4.1  Standards.  Base  standards  for  multiplex  formats  are  presented  in  table  3.7-31 . 


TABLE  3.7-31  Multiplex  format  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m§Hj 

NPC 

ANSI 

Telecommunication*  •  Synchronous  Optical  Ndwoifc 
(SONET)  -  Buie  Description  Including  Multiplex 
Structure,  Rate*  and  Format*  (ATIS)  (Reviaion  and 
Consolidation  of  ANSI  TU05-1991  and  ANSI  T1.105A- 
1991).  1995 

T1.105 

Mandated 

(Approved) 

NPC 

ANSI 

Digital  Hierarchy  -  Forman  Specifications,  1995 

Tl.  107 

Mandated 

(Approved) 

IPC 

ITU-T 

Synchronous  Frame  Structure*  Used  at  Primary  and 
Secondary  Hierarchical  Levels  (forE-1) 

G.7« 

Informational 

(Approved) 

3.7.6.4.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.6.4.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.6.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.6.4.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  ANSI  Tl.l  19,  Telecommunications  -  Synchronous  Optical  Network  (SONET)  - 
Operations,  Administration,  Maintenance,  and  provisioning  (OAM&P) 
Communications. 

2.  ITU-T  G.782,  Types  and  General  Characteristics  of  Synchronous  Digital 
Hierarchy  (SDH)  Multiplexing  Equipment. 

3.7.6.4.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  ANSI  T1 , 105  specifies  the  multiplexing  format  supported  by  SONET  systems. 
SONET  multiplexing  results  in  a  family  of  standard  rates  and  formats,  which  are 
multiples  of  the  basic  5 1 .84-Mbps  Synchronous  Transport  Signal  Level- 1  (STS- 1 ) 
rate.  SONET  systems  support  sub-STS- 1  rate  signals  by  multiplexing  lower-rate 
signals  onto  a  SONET  format. 

b.  The  multiplex  formats  applicable  to  DS 1  and  DS3  interfaces  are  defined  in  ANSI 
Tl.l  07. 
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3.7.6  J  Tactical  digital  information  links.  Standard  message  formats  and  related  information 
for  tactical  digital  information  links  (TADIL)  are  published  in  documents  called  TADILs.  A 
TADIL  consists  of  a  combined  information  medium  and  hardware  protocol,  and  a  message  format 
standard.  The  waveform  standard  is  identified  in  3.7.6.5.I.  Information  exchange  standards  are 
addressed  in  ITSG  Part  5.  TADILs  are  migrating  away  from  unique  data  links  to  achieve 
seamless  information  exchange.  TADILs  will  conform  to  a  standardized  TADIL  family.  All 
TADILs  will  migrate  to  this  standard  unless  granted  a  migration  exemption.  The  J-Series  Family 
of  TADILs,  described  fully  in  the  Joint  Tactical  Data  Link  Management  Plan  (JTDLMP),  dated 
April  1996,  enables  this  migration  while  accommodating  differences  in  information  exchange 
requirements. 

3.7.6 .5.1  Standards.  Base  standards  for  TADILs  are  presented  in  table  3.7-32. 

(Note:  STANAGs  for  TADILs  are  presented  in  3.7. 8. 7.) 


TABLE  3.7-32  TADIL  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mu 

GPC 

DOD 

JTIDS  Syitem  Segment  Specification  (Claa*  2  Terminal) 

JTIDS  Spec 

Mandated  j 

(Approved)  \ 

GPC 

DOD 

Interoperability  and  Performance  Standard  for  TADIL  A 

Legacy  [ 

(Approved) 

GPC 

DOD 

M1L-STD- 188-2 12 
of  10/17/1992 

Legacy 

(Approved) 

GPC 

DOD 

MIL-STD-188- 
203-3  of  10/5/88 

l-eg*cy 

(Approved) 

GPC 

DOD 

Manual  for  Employing  Joint  Tactical  Communication*  (for 
ATDL-I) 

CJCSM  6231 

Legacy 

(Approved) 

. 

lllili 

Wm 

j 

3.7.6.5.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.6.5.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.6.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.6.5.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1.  STANAG  4175,  Technical  Characteristics  of  the  Multi-functional  Information 
Distribution  System  (for  TADIL  J). 

2.  STANAG  5516,  Tactical  Data  Exchange  Link-16  (for  TADIL  J). 


April  7,  1997 


3.7-72 


Version  3.1 


Information  Technology  Standards  Guidance 


Communications  And  Network  Services 


3.7.6.5.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  Technical  characteristics  of  TADIL  A  subsystems  are  specified  in  MIL-STD- 188- 
203-1. 

b.  Technical  characteristics  of  TADIL  B  subsystems  are  specified  in  MIL-STD- 1 88- 

212. 

c.  Technical  characteristics  of  TADIL  C  subsystems  are  specified  in  MIL-STD- 188- 
203-3. 

d.  Technical  characteristics  of  Army  Tactical  Data  Link- 1  (ATDL- 1 )  are  specified  in 
CJCSM  6231. 

e.  Link  22  messages  will  be  used  for  the  exchange  of  maritime  operational  data 
between  tactical  data  systems  using  line-of-sight  (LOS)  UHF  radio  and  HF  radio 
for  beyond  LOS.  The  Link  22  standard  is  under  development 
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3.7.7  Strategic/tactical  interoperability.  Legacy  tactical  networks  are  based  on  Tri-Service 
Tactical  Communications  (TRI-TAC)  specifications.  Future  tactical  and  strategic  networks  will 
be  based  on  the  same  set  of  commercial  standards,  eliminating  current  interoperability  problems 
that  result  from  using  military-unique  standards  in  tactical  systems.  In  the  meantime, 
strategic/tactical  gateway  facilities  will  be  needed  to  achieve  interoperability.  Gateways  will 
support  five  capabilities: 

•  Five  levels  of  precedence  and  preemption 

•  Common-channel-signaling  message  conversion 

•  Choice  of  rate  adaptation  or  transcoding  for  voice  algorithm  conversion 

•  Direct  digital  interfacing  that  preserves  bit-count  integrity  (BCI) 

•  Support  of  end-to-end  transmission  and  reception  of  secure  voice  and  secure  data. 

3.7.7. 1  Transcoding.  A  transcoder  performs  direct  digital-to-digital  conversion  between  two 
different  voice-encoding  schemes  without  returning  the  signals  to  analog  form.  For  nonsecure 
voice,  strategic/tactical  gateway  facilities  will  transcode  PCM-encoded  voice  to  and  from  CVSD- 
encoded  voice.  The  method  of  transcoding  does  not  need  to  be  standardized.  It  is  necessary  only 
to  meet  the  PCM  interface  standard  on  one  side  and  the  CVSD  interface  standard  on  the  other 
side  of  the  transcoder. 

3.7.7.1.1  Standards.  Base  standards  for  transcoding  are  presented  in  table  3.7-33. 


TABLE  3.7-33  Transcoding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status  1 
DoD 

(Lifecycle)  1 

IPC 

ITU-T 

Pul»e  Code  Modulation  (PCM)  of  voice  frequencies 
(narrowband) 

0.711:1989 

Adopted 

(Approved) 

GPC 

DOD 

Analog-to-DigiUl  Conversion  Techniques  (for  CVSD 
Modulation) 

M1L-STD- 188-1 13 

Leg«ty  1 

(Approved) 

3.7.7.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.7. 1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.7. 1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.7. 1.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

STANAG  4209,  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Standards  for 
Analogue  to  Digital  Conversion  of  Speech  Signals. 
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3.7 .7.1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

The  standards  for  PCM  and  CVSD  are  ITU-T G.71 1  and  MIL-STD- 188-1 13,  respectively. 
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3.7.7 2  Rate  adaptation.  Information  sources  that  operate  at  rates  of  600, 1200, 2400, 4800, 
9600, 16000, 19200,  or  32000  bps  may  be  rate-adapted  to  a  64-kbps  channel. 

3.7.7.2.1  Standards.  Base  standards  for  rate  ''Captation  are  presented  in  table  3.7-34. 


TABLE  3.7-34  Rate  adaptation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Ml 

IPC 

ITU-T 

Support  of  Data  Terminal  Equipment*  (DTE*)  with  V- 
■eries  Interface*  by  ISDN 

V.l  10 

Legacy 

(Approved) 

IPC 

rru-T 

Multiplexing,  Rate  Adaptation  and  Support  of  Existing 
interface* 

1.460 

Legacy 

(Approved) 

GPC 

DOD 

Interoperability  Standard*  for  Data  Adapter  Control  Mode 
(for  mu  ki  templing) 

MIL-STD-  >88-216 

Legacy 

(Approved) 

3.7.7.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
2.1.1.22  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.7.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7 .7.2.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

ITU-T  1.464  Multiplexing,  Rate  Adaptation  and  Support  of  Existing  Interfaces  for 
Restricted  64  kbits/s  Transfer  Capability  -  Integrated  Services  Digital  Network  (ISDN)  - 
Overall  Network  Aspects  and  Functions,  ISDN  User-Network  Interfaces. 

3.7 .7.2. 6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

The  rate  adaptation  of  bit  rates  up  to  32  kbps  uses  the  multi-stage  approach  defined  in  ITU-T 
V.l  10,  the  section  titled  Adaptation  ofV-series  data  signaling  rates  to  the  intermediate  rates. 
Rate  adaptation  of  8-,  16-,  and  32-kbps  signals  is  accomplished  in  accordance  with 
ITU-T  1.460,  the  section  titled  Rate  adaptation  of  8-,  16-,  and  32-kbps  streams.  Information 
sources,  linked  to  a  tactical  network,  that  operate  at  rates  of  75,  600,  1200,  2400, 4800,  or 
9600  bps,  may  be  rate-adapted  to  a  16-kbps  channel,  as  described  :,.i  M1L-STD- 188-2 16,  the 
section  titled  Multisampling. 
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3.7.7  J  Signaling  message  conversion.  Interoperability  between  tactical  circuit  switches  and 
ISDN  circuit  switches  will  occur  through  appropriate  transformation  of  signaling  messages  at  the 
gateway  function.  The  gateway  function  translates  out-of-band  signaling  messages  between  the 
tactical  circuit-switched  network  and  ISDN  switched  networks  for  calls  initiated  in  either 
direction. 

3.7.7  J.I  Standards.  The  base  standard  for  signaling  message  conversion  is  presented  in  table 
3.7-35. 


TABLE  3.7-35  Signaling  message  conversion  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Kin 

GPC 

DOD 

AJI-DigiUl  Tactical-to- Strategic  Gateway 

MU  3HM8&-105 

I-egacy 

(Approved) 

3.7.7.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.7.3  J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.7.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.7.33  Related  standards.  No  related  standards  have  been  identified. 

3.7 .7.3.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

Signaling  me.  ,age  conversion  for  the  tactical-to-strategic  gateway  is  defined  in  M1L-STD- 
188-105. 
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3.7.8  NATO  interoperability.  NATO  standardization  agreements  (STANAGs)  identified  in  this 
section  are  agreements  between  NATO  nations  foi  the  interoperability  of  their  communications 
networks  and  end  systems. 

3.7.8.1  NATO  tactical  digital  gateway.  The  interface  between  U.S.-tactical  and  NATO-tactical 
switched  networks  will  comply  with  the  series  of  STANAGs  developed  for  the  NATO  Digital 
Gateway.  This  series  of  STANAGs,  is  based  to  a  large  degree  on  U.S.  legacy  tactical  circuit- 
switch  specifications. 

3.7.8.1.1  Standards.  Base  standards  for  the  NATO  Tactical  Digital  Gateway  are  presented  in 
table  3.7-36. 


TABLE  3.7-36  NATO  tactical  digital  gateway 

standards 

Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 
Sytfem  Standards 

STANAG  4206 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway  Mux 
Group  urming 

STANAG  4207 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 
Signaling  Meaaagea  and  Protocol* 

STANAG  4208 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway  A/D 
Conversion  of  Speech 

STANAG  4209 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 
Metallic  Cable 

STANAG  4210 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 
Syatem  Control 

STANAG  4211 

Lojicy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway  Radio 
Relay 

STANAG  4212 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 
Routing 

STANAG  4214 

Legacy  J 

(Approved)  U 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway  Fiber 
Optic  cables 

STANAG  4290 

Legacy  H 

(Approved)  I 

3.7.8.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.8. 1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.8.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.1.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

1 .  STANAG  42 1 3,  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Data 
Transmission  standards. 
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2.  STANAG  4249,  The  NATO  Multi-Channel  Tactical  Digital  Gateway  -  Data 
Transmission  standards  (Packet  Switching  Service). 

3.7 .8.1.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

The  interface  between  U.S.  tactical  circuit-switch  networks  and  NATO  tactical  circuit-switch 
networks  will  be  based  on  STANAGs  4206  to  42 12, 4214,  and  4290. 
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3.7.&2  Packet-switch  networks.  The  network-to-network  interface  between  U.S.-tactical  and 
NATO-tactical  packet-switched  networks  will  comply  with  STANAG  4249.  STANAG  4249 
specifies  the  network-to-network  international  interface  for  tactical  packet-switch  networks.  To 
achieve  DTE-to-DTE  interoperability  across  NATO  gateway  links  requires  additional  agreements. 
This  is  being  worked  in  several  NATO  technical  working  groups.  The  agreement  expected  will 
use  TCP/IP,  which  is  independent  of  the  underlying  subnetworks,  including  LANs,  that  may  exist 
in  national  networks. 

3.7.8 .2.1  Standards.  The  base  standards  for  interfacing  packet-switch  networks  across  a  NATO 
Tactical  Digital  Gateway  are  presented  in  table  3.7-37. 


TABLE  3.7-37  Packet-switch  network  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

NATO  Standardized  Profile  -  Connection-oriented  Mode 
Gateway  Between  Tactical  Packet-Switched  Data 
Network!  Uiuut  Digital  Data  Circuits 

STANAG  4249 

Legacy 

(Approved) 

IPC 

NATO 

The  NATO  Multi-Channel  Tactical  Digital  Gateway 

STANAG  4213 

Legacy 

(Approved) 

3.7.8.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.8.2.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.8.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.2.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  include  '  in  the  base  standards. 

1.  1AB  STD-35,  ISO  Transport  Service  on  Top  of  the  TCP. 

2.  RFC  1356,  Multiprotocol  Interconnect  on  X.25  and  ISDN  in  the  Packet  Mode. 

3.7 .8.2.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  STANAG  4249  supports  both  switched  virtual  circuits  (SVC)  and  permanent 
virtual  circuits  (PVC)  across  NATO  gateway  links.  SVCs  and  PVCs  will  support 
connectionless  IP  traffic  between  terminals  on  different  national  subnetworks. 

b.  STANAG  4213  specifies  the  forward  error  correction  code  applicable  to  the  layer 
1  interface  between  tactical  packet-switch  networks. 
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3.7  A3  NATO  data  network.  Current  NATO  standards  for  data  networks  are  aligned  with  the 
OSI  reference  model.  It  is  expected  that  NATO  standards  will  be  expanded  to  support  IP  router 
networks. 

3.7.8.3.1  Standards.  Base  standards  for  NATO  data  networks  are  presented  in  table  3.7-38. 


TABLE  3.7-38  NATO  data  network  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Statue 

DoD 

(Lifecycle) 

IPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  1  (PhyaicaJ  Layer) 
Service  Definition 

STANAG  4251 

Legacy 

(Approved) 

IPC 

NATO 

STANAG  4252 

Legacy 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  3  (Networic  Layer) 
Service  Definition 

STANAG  4253 

Legacy 

(Approved) 

IPC 

NATO 

NATO  Reference  Mode)  for  OSI  Layer  5  (Seetion  Layer) 
Service  Definition 

STANAG  4255 

Let«cy 

(Approved) 

IPC 

NATO 

NATO  Reference  Mode)  for  OSI  Layer  6  (Plantation 
Layer)  Service  Definition 

STANAG  4256 

Legacy 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  1  (Phyaical  Layer) 
Protocol  Specification 

STANAG  4261 

Letecy 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  2  (Data  Link 
Layer)  Protocol  Specification 

STANAG  4262 

Legacy 

(Approved) 

IPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  3  (l .  Xwork  Layer) 
Protocol  Specification 

STANAG  4263 

Legacy 

(Approved) 

CPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  5  (Seition  Layer) 
Protocol  Specification 

STANAG  4265 

Lcj«cy 

(Approved) 

EPC 

NATO 

NATO  Reference  Model  for  OSI  Layer  6  (Preaentanon 
Layer)  Protocol  Specification 

STANAG  4266 

Legacy 

(Approved) 

3.7.5.3.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.8.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 
However,  there  are  some  NATO  efforts  to  enhance  the  capability  of  NATO  data  network 
standards. 

3.7.8.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.3.5  Related  standards.  No  related  standards  have  been  identified. 

3.7.8.3.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

The  STANAG  4250  series  defines  the  services  that  a  layer  provides  to  the  layer  above.  The 
STANAG  4260  series  defines  the  protocols  for  operation  between  layer  peers. 
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3.7.M  Digital  facsimile.  Facsimile  transmissions  requiring  interoperability  with  NATO  countries 
will  use  digital  facsimile. 

3. 7.8.4. 1  Standards.  The  base  standard  for  facsimile  interoperability  with  NATO  allies  is  given 
in  table  3.7-39. 


TABLE  3.7-39  Facsimile  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

NATO 

Interoperability  for  Tactical  Digital  Facsimile 

STANAG  5000 

Legecy 

(Approved) 

3.7.8.4.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.8.4J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.8.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.4.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

EIA/T1A-466-A,  Procedures  for  Document  Facsimile  Transmission. 

3.7 .8.4.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

Facsimile  transmissions  requiring  encryption  or  interoperability  with  NATO  countries  will  use 
digital  facsimile,  as  defined  in  STANAG  5000. 
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3.7.8.5  Single  channel  radios.  Voice  and  data  may  be  exchanged  between  different  national 
forces  using  single  channel  radios. 

3.7.&5.1  Standard.  Base  standards  for  single  channel  radios  for  NATO  are  presented  in 
Table  3.7-40. 


TABLE3!7^0iJing[echanneliradio^and^rdstoriNATO 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

NATO 

Tranamisiion  Characterirtica  lor  Dm*  Exchange  between 
Lend  Tactical  Dele  Processing  Equipment  over  Single 
Channel  Radio  Links 

STANAG  4202 

Legecy 

(Approved) 

IPC 

NATO 

Technical  Standard  for  Single  Channel  HF  Radio 
Equipment 

STANAG  4203 

Legecy 

(Approved) 

IPC 

NATO 

Technical  Standard  for  Single  Channel  VHF  Radio 
Equipment 

STANAG  4204 

Legacy 

(Approved) 

IPC 

NATO 

Technical  Standard  for  Single  Channel  UHF  Radio 
Equipment 

STANAG  4205 

Legecy 

(Approved) 

IPC 

NATO 

Secure  and  Jam*  real  slant  HP  Low  Speed  Data 
Communication!  Syatem 

STANAG  4245 

Legecy 

(Approved) 

IPC 

NATO 

HAVE  QUICK:  UHF  Secure  and  Jam-reaiatant  Low  Speed 
Data  Communication!  Equipment 

STANAG  4246 

Legecy 

(Approved) 

IPC 

NATO 

1200/2400/3600  MODEM  for  HF  Radio  Linka 

STANAG  4285 

Legecy 

(Approved) 

IPC 

NATO 

Standard!  to  Achieve  Communication  between  Single 
Channel  Tactical  Combat  Net  Radio  Equipment  and 
Frequency  Hopping  Radios  Operating  in  the  VHF  Band 
(30- 88  MHZ) 

STANAG  4292 

Legecy 

(Approved) 

IPC 

NATO 

SATURN,  a  Fast  Frequency  Hopping  ECCM  mode  for 

UHF  Radio 

STANAC  4372 

Legacy 

(Approved) 

3.7.8.5.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.8.5.3  Standard  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.8.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.5.5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

STANAG  429 1 . 2400  wireless  modem. 

3.7 .8.5.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 


a.  STANAG  4202  defines  the  error  detection  and  correction  techniques  for  DTEs  to 
exchange  information  over  HF,  VHF,  and  UHF  single  channel  radios. 
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b.  STANAG  4203  defines  the  technical  characteristics  for  single  channel  HF  radio 
equipment 

c.  STANAG  4204  defines  the  technical  characteristics  for  single  channel  VHF  radio 
equipment 

d.  STANAG  4205  defines  the  technical  characteristics  for  transmission  of 
voice/data/teletype  over  single  channel  UHF  radio  equipment 

e.  STANAG  4246  defines  the  technical  characteristics  for  airborne  radios  operating 
at  UHF. 

f.  STANAG  4285  defines  the  call  establishment  procedures  and  modem 
characteristics  for  low  speed  data  transmission  over  HF  radio  links. 
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3J.8.6  Satellites.  UHF  satellites  may  be  used  to  support  exchange  of  voice  and  data  between 
different  national  forces. 

3.7.8.6.1  Standard.  Base  standards  for  Satellites  for  NATO  are  presented  in  Table  3.7-41. 


TABLE  3.7-41  Satellite  standards  for  NATO 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

NATO 

Digiul  IflteropertbiHty  between  UHF  SMeUite 
ComitMimqriona  Tonnineli 

STAN  AO  4231 

(Approved) 

3.7.8.6 J2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 
3.7.8.6  J  Standard  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.8.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.6 .5  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

MIL-STD-188-181,  Interoperability  Standard  for  Dedicated  5-kHz  and  25-kHz  UHF 
Satellite  Communications  Channels. 

3.7 .8.6.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

STANAG  423 1  specifies  the  minimum  necessary  parameters  to  achieve  interoperability  of  UHF 
SATCOM  terminals  for  teletype,  low  speed  data,  or  voice. 
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3.7 .8.7  TADILs.  Standard  message  formats  and  related  information  for  tactical  digital 
information  links  (TADIL)  are  published  in  documents  called  TADILs.  TADIL  J  has  been 
standardized  for  use  in  NATO. 

3.7.8.7.1  Standard.  Base  standards  for  TADILs  are  presented  in  Table  3.7-42. 


TABLE  3.7-42  NATO  TADILs  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

\ 

KliSSSBB 

I?C 

NATO 

Technical  Characteristics  of  the  Multifunctional 
Information  Distribution  System  (MIDS) 

STANAG  4 175, 
Edition  1,  August 
29. 1991 

Mandated 

(Annoyed) 

3.7.8.7.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.7.8.7 3  Standard  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.S.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.8.7J  Related  standards.  Related  standards  are  informative  documents  related  to  the  base 
standards.  Normative  references  are  included  in  the  base  standards. 

STANAG  5516,  Tactical  Data  Exchange  Link- 1 6  (for  TADIL  J) 

3.7.8.7.6  Recommendations.  The  following  base  standards  should  be  used  in  support  of  related 
procurements: 

Technical  characteristics  and  waveform  parameters  of  TADIL  J  subsystems  are  specified  in 
STANAG  4175. 
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3.7.9  Communications  and  network  services  security.  Communications  and  network  services 
security  protects  the  information,  components,  and  mechanisms  of  the  communications  and 
network  system.  Use  of,  and  compliance  with,  the  security  standards  identified  in  this  document 
does  not  constitute  authorization  to  process  classified  data.  DOD  policy  covering  the  security 
accreditation  process  must  still  be  followed  to  obtain  approval  for  processing  classified  data. 

3.7.9.1  Network  security  architecture.  (This  BSA  appears  in  both  part  7  and  part  10.)  OSI 
security  architecture  defines  the  general  security-related  architectural  elements,  provides  a  general 
description  of  security  services  and  related  mechanisms,  and  defines  the  positions  within  the  OSI 
Reference  Model  at  which  the  services  and  mechanisms  may  be  provided.  Open  systems  security 
frameworks  address  data  elements  and  sequences  of  operations  that  are  used  to  obtain  security 
services. 

Note:  The  security  architecture  and  framework  standards  are  intended  to  provide  guidance  and 
background  information  to  developers.  In  general,  these  standards  do  not  provide  implementable 
specifications  against  which  conformance  can  be  claimed. 

3.7.9.1.1  Standards.  Table  3.7-43  presents  standards  for  network  security  architecture. 


TABLE  3.7-43  Network  security  architecture  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Tmrted  Computer  Sy itemi  Evolution  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  Interpretation 

i mmm 

Mandated 

(Approved) 

IPC 

ISO 

7498-2:1989 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Syitemi  •  Put  2: 
Authentication  Frame  wo  tk 

10181-2:1996 

Informational 

(Approved) 

IPC 

ISO 

OSI  Upper  I,ayer  Security  Model 

10745:1993 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  I :  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Lower  Layer  Security  Model 

TR  13594:1995 

Informational 

(Approved) 

Wm&SM 

1 

1  ■ 

SMB 

HfcjjjB 

111 

ISlill 

WKSM 

gjjj 

bc 

1 

Mm**** f 

WmM Wm 

1 

WMEC 

fc  torn* 

iiSilllillill 

MBSil 
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3.7.9.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.1.3  Standards  deficiencies.  The  Upper  Layer  Security  Model  (ISO  10745)  primarily 
addresses  FTAM  requirements  and  does  not  deal  with  Directory,  Transaction  Processing,  and 
X.400. 


3.7.9. 1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.9. 1.5  Related  standards.  NCSC-TG-01 1,  Version  1,  1  August  1990,  Trusted  Network 
Interpretation  Environments  Guideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation  is  a  guideline  supporting  the  TCSEC. 

3.7.9.1.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 
Implementations  involving  security  services  should  require  conformance  to  the  security  principles 
and  concepts  of  the  DGSA  (TAFIM,  Volume  6)  and  supporting  standards.  RFC  1825  is  an 
emerging  standard  that  provides  the  current  view  of  how  to  implement  security  functions  within 
an  Internet  Protocol  (IP)  suite  network.  The  Internet  Draft  document  draft-ietf-ipsec-arch-sec- 

0 1  .txt  is  a  "work-in-progress"  revision  of  RFC  1 825. 
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3.7.9.2  Security  risk  management.  (This  BSA  appears  in  part  2,  part  7,  part  9,  and  part  10.) 
Security  risk  management  supports  accreditation  through  a  risk  analysis  of  an  information  system 
and  its  operational  environment,  and  the  steps  taken  to  manage  the  risk  requirements. 

3.7.9.2.1  Standards.  Table  3.7-44  presents  standards  for  security  risk  management 


TABLE  3.7-44  Security  risk  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Tiusted  Computer  Syitemt  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guide  line  for  the  Analyst*  of  Local  Area  Network  Security 

FIPS  PUB 
191:1994 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Automated  Data  Processing  Risk  Analysis 

FIPS  PUB  65:1979 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Automatic  Data  Processing  Physical 
Security  and  Risk  Management 

FIPS  PUB  31:1974 

Informational 

(Approved) 

3.7.9.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.2J  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  3 1  does  not  include  information 
about  modem  security  concepts. 

3.7.9.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.7.9.2.5  Related  standards.  The  following  standards  are  related  to  the  TCSEC  str-dard: 

a.  CSC-STD-003-85  25  June  1985,  Computer  Security  Requirements  -  Guidance  for 
Applying  the  Department  of  Defense  Trusted  Computer  Security  Evaluation 
Criteria  in  Specific  Environments 

b.  CSC-STD-004-85,  25  June  1985,  Technical  Rationale  Behind  CSC-STD-003-85: 
Computer  Security  Requirements  -  Guidance  for  Applying  the  Department  of 
Defense  Trusted  Computer  Security  Evaluation  Criteria  in  Specific  Environments 

3.7 .9.2.6  Recommendations.  The  mandated  standard  is  recommended.  Office  of  Management 
and  Budget  (OMB)  Circular  A- 130,  "Management  of  Federal  Information  Resources,"  provides 
guidance  on  effective  security  risk  management  of  federal  information  systems.  NIST  Special 
Publication  800-12,  "An  Introduction  to  Computer  Security:  The  NIST  Handbook"  provides 
additional  guidance  on  risk  management.  DOD  Directive  5200.28  requires  a  risk  analysis  of  an 
information  system  be  conducted  in  its  operational  environment  to  support  accreditation  of  the 
information  system.  System  implementors  should  perform  the  risk  analysis  in  accordance  with 
CSC-STD-003-85  and  CSC-STD-004-85  to  determine  the  appropriate  DOD-5200.28-STD  class. 
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3.7.9 3  security  management.  (This  BSA  appears  in  part  7,  part  8,  part  9,  and  part  10.) 

Security  management  is  a  particular  instance  of  information  system  management  Security 
management  provides  supporting  services  that  contribute  to  the  protection  of  information  and 
resources  in  open  systems  in  accordance  with  information  domain  and  information  security 
policies.  The  basic  elements  that  must  be  managed  are  users,  security  policies,  information, 
information  processing  systems  that  support  one  or  more  security  policies,  and  the  security 
functions  that  support  the  security  mechanisms  (automated,  physical,  personnel,  or  procedural) 
used  to  implement  security  services.  For  each  of  these  elements,  the  managed  objects  that 
constitute  them  must  be  identified  and  maintained.  For  example,  users  must  be  known  and 
registered,  security  policies  must  be  represented  and  maintained  and  information  objects  must  be 
identified  and  maintained.  Security  policies,  security  services  and  security  mechanisms  are  the  first 
classes  of  managed  objects. 

3. 7. 9.3.1  Standards.  Table  3  7-45  presents  standards  for  security  management 


TABLE  3.7-45  Security  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Referent 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandtfed 

(Approved) 

GPC 

DOD 

Trusted  Net  wort  Interpretation 

NCSC-TG-005. 
Version  1:  1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-021, 
Version  1: 1991 

Mandated 

(Approved) 

CPC 

OSH 

Distributed  Computing  Environment  ,'DCE)  Security 
Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

1PC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
ref:  ISO  9594-4) 

X.5I8:  1993 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

[PC 

ISOAEC 

OSI  Common  Management  Information  Services  (CM1S) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4-.1992 

Informational 

(Approve.!) 

(pc 

ISO/IEC 

Information  Technology  -  Open  Systems  Interconnection  - 
Common  Management  Information  Protocol  (CMIP)  -  Part 

1 :  Specification  (Includes  amemfcr>en(  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profile  Sets  1 1 183-X.  12059- 
X.  and  12060-X.  includes  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Infoimational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  7:  Security  Alarm 
Reporting  Function  (same  as  ITU-T  X.736) 

10164-7* 1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management.  Part  8:  Security  Audit  Trail 
Function  (same  as  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management.  Part  9:  Objects  and  Attributes 
for  Access  Control 

10164-9:1995 

Informational 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model.  Part  2:  Security  Architecture 
(same  as  CCI 71  X. 800: 1991) 

7498-2:1989 

Informational 

(Approved) 

(IPC 

NISI' 

Government  Networi  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 
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3.7.9.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.3J  Standards  deficiencies.  Deficiencies  exist  in  standardization  of  security  policy  rule 
representation;  key  management,  including  generation,  distribution,  and  accounting;  audit 
information  formats;  exchange  of  security  management  information;  and  remote  security 
management 

The  DGSA  principle  of  decision  and  enforcement  separation  requires  that  the  functions 
determining  how  to  enforce  a  security  policy  and  the  actual  enforcement  of  the  policy  be 
implemented  independently.  That  is,  the  enforcement  mechanisms  do  not  need  any  knowledge  of 
security  pnlicy.  Standards  are  needed  for  object  class  definitions  for  classes  of  managed  objects 
and  for  methods  of  representing  security  policy. 

The  DGSA  calls  for  a  separation  mechanism,  such  as  separation  kernel,  to  mediate  all  calls  to 
security  critical  functions  to  ensure  that  strict  isolation  is  maintained.  Standardization  of  object 
class  definitions  for  management  of  critical  functions  used  within  the  separation  kernel  is  needed. 

The  present  ISO/IEC  10164-7  "Security  Alarm  Reporting  Function,"  and  10164-8,  "Security 
Audit  Trail  Function,"  standards  were  designed  with  network  security  in  mind.  Little  work  has 
been  done,  either  in  standards  groups  or  in  products,  on  how  to  use  these  standards  for  general 
system  management  (e.g.,  computer  systems  and  software). 

FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  The  present  GNMP  specifications  require  ISO 
Common  Management  Information  Service/Protocol  (CM1S/CMIP)  to  communicate  management 
information  and  ISO  OSI  networking  protocols.  Plans  are  for  the  GNMP  eventually  to  provide  a 
capability  to  integrate  the  present  GNMP  with  Simple  Network  Management  Protocol  (SNMP). 
One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 
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No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 

The  Institute  of  Electrical  and  Electronic  Engineering  (IEEE)  POSIX  Security  Working  Group 
(formerly  P1003.6)  is  defining  security  extensions  to  the  base  POSIX  interface  standard  (ISO 
9945-1),  to  include  support  for  audit,  privilege,  discretionary  and  mandatory  access  control,  and 
infoimation  labels.  These  have  been  redesignated  IEEE  P1003.1c  and  IEEE  P1003.2c.  The  draft 
standards  are  still  incomplete,  and  the  specifications  may  change. 

The  POStX/UNIX  permission  bits  are  inadequate  for  fine-grained  control  over  exactly  which 
users  can  perform  specified  actions  to  particular  files. 

In  the  IETF,  efforts  to  develop  an  acceptable  security  standard  for  SNMPv2  have  been  on  hold 
since  September  1995  when  the  IETF  SNMP  Working  Group  failed  to  agree  on  the  proposals 
submitted.  Since  then,  two  sets  of  proposals  for  providing  SNMPv2  security  have  emerged.  The 
first  set  of  proposed  specifications,  the  User-based  Security  Model  (USEC),  also  referred  to  as 
SNMPv2u,  consists  of  two  documents:  RFC  1909,  "An  Administrative  Infrastructure  for 
SNMPv2"  and  RFC  1910,  "The  User-based  Security  Model  for  SNMPv2."  Both  RFCs  were 
issued  28  February  1996  and  are  classified  by  the  IETF  as  experimental  RFCs.  The  other 
proposal  is  known  as  SNMPv2*,  which  its  proponents  claim  is  heavily  based  on  USEC.  Neither 
USEC  nor  SNMPv2*  has  been  approved  for  a  standards  track  by  IETF. 

3.7.9.3.4  Portability  caveats.  The  structure  of  certain  traditional  UNIX  directories,  such  as  the 
familiar  7tmp,"  "/usr/spool,"  and  "/usr/spool/mail"  directories  must  be  expressly  managed  to 
accommodate  the  P1003.1e  and  P1003.2c  security  standards.  This  is  because  these  are 
directories  to  which  all  users  have  access  and  to  which  many  programs  write.  A  change  in  the 
way  programs  write  to  directories  has  the  potential  for  causing  software  portability  and  systems 
administrator  portability  problems. 

The  traditional  UNIX  permission  bits  that  have  been  carried  into  POSIX  are  inadequate  for 
defining  exactly  which  user  can  perform  specific  actions  on  specific  files.  Eliminating  the 
permission  bits  in  favor  of  Access  Control  Lists  could  make  the  secure  POSIX  systems 
incompatible  with  non-POSIX  compliant  systems  and  many  applications. 

OSF  DCE  Version  1.1's  authentication  services  are  based  on  Kerberos  Version  5  (RFC  1510),  but 
is  not  totally  compatible  with  RFC  1510.  DCE  1.2,2  adds  testing  and  official  support  for 
Kerberos  Version  5. 

3.7.9.3.5  Related  standards.  ISO/IEC  9945-1  as  profiled  by  FIPS  PUB  151-2  is  related  to  IEEE 
P1003.1e  and  IEEE  P1003.2c. 

3.7.9.3.6  Recommendations.  The  mandated  standards  are  recommended. 

All  IEEE  P1003.1e  and  IEEE  P  1003.2c  security  systems  should  incorporate  Access  Control  Lists 
as  an  optional  feature  in  addition  to  permission  bits  (not  "in  place  of”  permission  bits).  The 
incompatibilities  between  the  two  access  control  methods  (permission  bits  and  access  control 
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lists)  are  not  resolvable.  The  best  method  for  resolving  the  overall  problems  seem  to  be 
incorporation  Access  Control  Lists  as  an  optional  feature  on  top  of  permission  bits.  The 
permission  bits  would  represent  the  lowest  common  denominator  of  security,  showing  the 
maximum  amount  of  openness  possible  in  a  system.  Organizations  needing  only  the  lowest  level 
of  security  could  continue  to  use  the  familiar  permission  bits  and  associated  "chmod"  command. 
(Jse  of  access  control  lists  will  require  a  change  in  security  policy  such  that  access  is  granted  if 
and  only  if  permission  is  granted  and  access  control  permits  it. 
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3.7.9.4  Security  association  and  key  management  (This  BSA  appears  in  part  7,  part  9,  and 
part  10.)  A  security  association  is  the  totality  of  communication  and  security  mechanisms  and 
functions  (e.g„  communications  protocols,  security  protocols,  doctrinal  mechanisms,  security- 
critical  mechanisms  and  functions)  that  securely  binds  together  two  security  contexts  in  different 
end  systems  or  relay  systems  supporting  the  samt  information  domain.  A  security  association  is  an 
application  association  that  includes  additional  support  from  security  functions  and  mechanisms. 
Key  management  provides  procedures  for  handling  cryptographic  keying  material  to  be  used  in 
symmetric  or  asymmetric  cryptographic  mechanisms.  It  includes  key  generation,  key  distribution, 
key  storage,  key  archiving,  and  key  deletion. 

3.7.9.4.1  Standards.  Table  3.7-46  presents  standards  for  security  association  and  key 
management 
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TABLE  3.7-46  Security  association  and  key  management  standards 


Standard 

Type 


Sponsor 


Standard 


Standard 

Reference 


Key  Exchange  Algorithm 


Mandated 


(Approved) 


SDN.903,  Version 


Secure  DaU  Network  System  (SDNS)  Key  Management 


Protocol  (KMP) 


(Approved) 


GPC 

NIST 

Key  Management  Using  ANSI  X9.I7 

FIPS  PUB 
171:1992 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Models,  and  Notation 

11586.1:1994 

Informational 

(Approved) 

IPC 

ISO 

11586-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  3 :  Security 
Exchange  Service  Element  Protocol  Specification 

11586-3:1994 

Informational 

(Approved) 

IPC 

ISO 

Banking  Key  Management  (wholesale) 

8732:1988 

Infotmational 

(Approved) 

NPC 

ANSI 

Financial  Institution  Key  Management  (wholesale) 

X9.I7-1991 

Infotmational 

(Approved) 
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3.7.9.42  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9A3  Standards  deficiencies  There  is  a  lack  of  guidance  for  establishing  a  Public  Key 
Infrastructure  (PK1)  to  automatically  manage  public  keys  through  the  use  of  public  key 
certificates.  In  April  1994,  National  Institute  of  Standards  and  Technology  (NIST),  in  conjunction 
with  seven  other  federal  agencies,  completed  a  study  on  automated  management  of  public  keys 
and  associated  public  key  certificates  on  a  nationwide  basis.  Based  on  the  recommendations  of  the 
study,  GSA  is  establishing  a  PKI  pilot  project  to  provide  public  key  certificate  services  for 
participating  government  agencies. 

3.7.9.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.9.4.5  Related  standards.  There  are  no  related  standards. 

3.7.9.4.6  Recommendations.  The  mandated  standards  are  recommended.  In  FORTEZZA 
applications,  the  NSA-developed  Key  Exchange  Algorithm,  R21-TECH-23-94,  must  be  used. 

IEEE  P1363,  Standard  for  Public-Key  Cryptography,  is  under  development,  with  the  first  version 
expected  to  be  ready  for  balloting  in  1997. 

The  lETF's  IP  Security  Protocol  (IPSEC)  Working  Group  (WG)  is  developing  an  Internet  Key 
Management  Protocol  (IKMP)  that  will  be  specified  as  an  application  layer  protocol  independent 
of  the  lower  layer  security  protocol.  The  IKMP  will  be  based  on  ISAKMP/Oakley  work  begun  in 
the  Internet  Draft  documents  for  ISAKMP  and  the  Oakley  Key  Determination  Protocol. 
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3.7.9.S  Security  audit.  (This  BSA  appears  in  part  7,  part  9,  part  10,  and  part  1 1.)  Security 
auditing  is  a  review  or  examination  of  records  and  activities  to  test  controls,  ensure  compliance 
with  policies  and  procedures,  detect  breaches  in  security,  and  indicate  changes  in  operation 
(paraphrased  from  ISO  7498-2). 

3. 7. 9.5.1  Standards.  Table  3.7-47  presents  standards  for  security  audit. 


TABLE  3.7-47  Security  audit  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trnated  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

CPC 

NMF 

OMNIPoim  1  (Adopts  ISO  Profile  Seta  1 1 183-X,  12059- 
X.  and  1206O-X,  include.  ISO/IEC  10164-X) 

OMNIFoint  1:1993 

Informational 

(Approved) 

[PC 

ISO/IEC 

OSI  Syitem*  Management,  Part  8:  Security  Audit  Trail 
Function  (tame  aa  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

CPC 

X/Opeo 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020: 1990 

Informational 

(Approved) 

3.7.9.5.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.5.3  Standards  deficiencies.  ISO  Transaction  Processing  Security  work  (WDAMs  to  ISO 
10026-1,2,3)  is  in  the  early  stages.  Its  content  is  nut  defined,  and  it  cannot  be  used  for 
procurement.  ISO  10164-8  does  not  define  a  security  audit,  or  explain  how  to  perform  one.  It 
does  not  define  implementation  aspects,  occasions  where  the  use  of  the  security  audit  trail 
function  is  appropriate,  or  the  services  necessary  for  the  establishment  and  normal  or  abnormal 
release  of  a  management  association. 

There  is  a  need  for  a  standard  for  programming  interfaces  to  support  development  of  portable 
tools  for  audit  trail  analysis  and  configuration. 

3.7.9.5.4  Portability  caveats.  Proposed  amendments  to  ISO  10026  have  ceased.  This  is  a  high 
portability  risk  area, 

3.7.9.5.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 
a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 
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b.  NCSC-TG-01 1,  Version  1, 1  August  1990,  Trusted  Network  Interpretation 
Environments  Guideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation 

c.  NCSC-TG-00 1 ,  Version  2,  June  1 988,  A  Guide  to  Understanding  Audit  in  Trusted 
Systems 

3.7.9.5.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.7.9.6  Security  alarm  reporting.  (This  BS A  appears  in  part  7,  part  9,  part  10,  and  part  1 1 .) 
Security  alarm  reporting  is  the  capability  to  receive  notifications  of  security-related  events,  alerts 
of  any  misoperations  in  security  services  and  mechanisms,  alerts  of  attacks  on  system  security,  and 
information  as  to  the  perceived  severity  of  any  misoperadon,  attack,  or  breach  jr  security, 

3.7.9.6.1  Standards.  Table  3.7-48  presents  standards  for  security  alarm  reporting. 


TABLE  3.7-48  Security  alarm  reporting  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

Dol) 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  1  (Adopu  ISO  Profile  S«j  1 1 I83X,  12059- 
X,  *nd  12060-X,  include*  ISO/EC  I0I64-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

1PC 

ISO/IEC 

OSI  Syitemi  Management,  Put  7:  Security  Alum 
Reporting  Function  (tune  u  ITU-T  X.736) 

10164-7:1992 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Infoimationel 

(Approved) 

(Mbimii 

3.7.9.6.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.6J  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  ISO  10164-7 
does  not  define  implementation  aspects,  specify  the  manner  in  which  management  is  accomplished 
by  the  user  of  the  Security  Alarm  Reporting  Function  (SARF),  define  interactions  that  result  in 
the  use  of  the  SARF,  or  specify  the  services  necessary  for  the  establishment  and  normal  and 
abnormal  release  of  a  management  association. 

3.7.9.6.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown 

3.7.9.6.5  Related  standards.  There  are  no  related  standards. 

3.7 .9.6.6  Recommendations.  There  are  no  recommended  standards  for  security  alarm  reporting. 
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3.7 .9.7  Network  authentication.  (This  BSA  appears  in  part  7  and  part  10.)  Network 
authentication  services  establish  the  validity  of  a  claimed  identity  (peer-entity)  or  origin  (data) 
(paraphrased  from  ISO  7498-2). 

3.7.9.7.1  Standards.  Table  3.7-49  presents  standards  for  network  authentication. 


TABLE  3.7-49  Network  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Information  Technology  -  Defooae  Stutdanhzed  Profile* 
AMHXn(D)-  Meaaage  Handling  Systems  -  Message 
Security  Protocol  (MSP)  Parts  1*5 

MIL-STD-2045- 
18500:  1993 

Mandated 

(Approved) 

IPC 

ITU-T 

‘Dte  Directory:  Authentication  Framework  (X-ref:  ISO 
9594-8) 

X.509,  Version  3: 
1993 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  Interpretation 

iaaa 

Mandated 

(Approved) 

GPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB  ISO- 
111995 

Mandated 

(Approved) 

GPC 

NSA 

Secure  Dria  Network  System  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.301,  Revision 
1.5:  1989 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Interface  Control  Document 

FORTEZZA  ICD 
Rev  PI. 5: 1994 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Plus  Interface  Control  Document 

FORTEZZA  Plus 
ICDRel  3.0: 1995 

Mandated 

(Approved) 

NPC 

IEEE 

Standard  for  Interoperable  LAN  Security  -  Part  B:  Secure 
Data  Exchange  (SDE) 

802.10b:1992 

Legacy 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701,  Rev.  3.0: 
1994 

Legacy 

(Approved) 

GPC 

NSA 

tsage  Security  Protocol  (MSP) 

SDN.701,  v.  4.0, 
Rev.  A:  1997 

Emerging 

(Approved) 

IPC 

ISO 

Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Service  Definition  for  the  Association 
Control  Service  Element  (ACSE),  Revised  Edition 

8649:1992 
(Incorporates  AM 
I&2) 

Informational 

(Approved) 

IPC 

ISO 

Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Protocol  Specification  for  the  ACSE, 
Revised  Edition 

8650:1992 
(Incorporates  AM 
U_ 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  2:Security 
Exchange  Service  Element  Definition 

11586-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  3:  Security 
Exchange  Service  Element  Protocol  Specification 

11586-3:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  4:  Protecting 
Transfer  Syntax  Specification 

11586-4:1994 

Informational 

(Approved) 

IPC 

ISO 

Transport  Layer  Security  Protocol  (TLSP)  (Includes 
Amendment  1) 

10736:1994 

Informational 

(Approved) 

IPC 

ISO 

Nelwoik  Layer  Security  Protocol  (NLSP) 

11577:1994 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/EC 

QSI  Security  Framework!  for  Open  Sy  item!  -  Pvt  2: 
Authentication  Framework 

10181-2:1996 

Informational 

(Annoved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

CPC 

IETF 

Privacy  Enhancement  for  Internet  Electronic  Mail 

Informational 

(Drift) 

GPC 

NSA 

Secure  D*U  Network  Syatem  (SDNS)  Security  Protocol  4 
(SP4) 

SDN.401,  Rev. 
1.3:1989 

Informational 

(AffMoved) 

GPC 

NSA 

Meaaage  Security  Protocol  (MSP)  with  MIME 

SDN.704,Rev.  1.4: 
1996 

Informational 

(Approved) 

3.7.9.7.2  Alternative  specifications.  There  ure  no  alternative  specifications. 

3.7.9.7J  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  Procurements 
requiring  authentication  in  FTAM  cannot  specify  a  standard  at  this  time.  The  ISO  FTAM  security 
effort  is  in  its  early  stages.  Current  proprietary  FTAM  security  is  based  on  passwords  for 
authentication.  ISO  TP  security  work  is  in  the  early  stages.  Its  content  is  not  defined,  and  it 
cannot  be  used  in  a  procurement. 

3.7.9.7.4  Portability  caveats.  Proposed  security  enhancements  to  FTAM  (WDAM4  to  ISO 
8571)  have  ceased.  This  is  a  high  portability  risk  area. 

3.7.9.7.5  Related  standards.  NCSC-TG-01 1,  Version  1,  1  August  1990,  Trusted  Network 
Interpretation  Environments  Guideline  -  Guideline  for  Applying  the  Trusted  Network 
Interpretation,  supports  NCSC-TG-005. 

3.7.9.7.6  Recommendations.  The  mandated  standards  are  recommended. 
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MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DOD 
Standardized  Profile  (DSP)  standard  will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to 
Allied  Communications  Publication  (ACP)  123  or  ACP  120,  Common  Security  Protocol,  when 
the  revision  to  MSP  is  complete. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

DSS  is  intended  to  specify  general  security  requirements  for  generating  digital  signatures. 
Conformance  to  this  standard  does  not  assure  that  a  particular  implementation  is  secure.  The 
responsible  authority  in  each  Government  agency  or  department  shall  assure  that  an  overall 
implementation  provides  an  acceptable  level  of  security.  DSS  can  be  used  in  electronic  mail, 
electronic  funds  transfer,  electronic  data  interchange,  software  distribution,  data  storage,  and 
other  applications  that  require  data  integrity  assurance  and  data  origin  authentication.  It  uses  the 
Secure  Hash  Algorithm  (SHA)  specified  in  FIPS  PUB  180-1,  which  supersedes  FIPS  PUB  180. 
NIST  is  developing  a  validation  program  to  test  implementations  for  conformance  to  DSS. 

The  following  two  documents  should  be  consulted  for  systems  required  to  interface  with  the 
Defense  Message  System  (DMS): 

a.  FORTEZZA  Interface  Control  Document,  Rev.  1.5,  22  December  1994 

b.  FORTEZZA  Plus  Interface  Control  Document,  Release  3.0,  1  June  1995 
SDN.701,  Rev.3.0,  is  used  with  DMS,  Phase  1.  It  is  for  use  with  legacy  systems  only. 

IEEE  802.10b  is  for  use  with  legacy  LANs  only. 
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3J.9.8  Network  access  control.  (This  BS A  appears  in  part  7,  part  9,  and  part  10.)  Access 
control  is  the  prevention  of  unauthorized  use  of  a  resource,  including  its  use  in  an  unauthorized 
manner. 

3.7.9.8.1  Standards.  Table  3.7-50  presents  standards  for  network  access  control. 


TABLE  3.7-50  Network  access  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

GPC 

DOD 

Information  Technology  -  Defense  Standardized  Profile* 
AMHXn(D)-  Menace  Handlin|  Syatem*  •  Message 
Security  Protocol  (MSP)  Parti  1-5 

MIL- STD- 2045- 
18500: 1993 

Mandated 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.30 1,  Revision 
1.5: 1989 

Mtftdaled 

(Approved) 

NPC 

tppf 

Standard  for  Interoperable  LAN  Security  -  Part  B:  Secure 
Data  Exchange  (SDE) 

802.1  Ob:  1992 

Legacy 

(Approved) 

1PC 

1SO/IEC 

OSI  Common  Management  Information  Service*  (CMJS) 
Definition,  with  Amendment  4:  Acte**  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

[PC 

ISO 

Traru port  Layer  Security  Protocol  (TLSP)  (Include* 
Amendment  1) 

10736:1994 

Informational 

(Approved) 

IPC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  for  Security  of  Computer  Application* 

FIPS  PUB  83:1980 

Informational 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Securit  ?rotocol  4 
(SP4) 

SDN.401.Rev. 

1.3:1989 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Informational 

(Superseded) 

GPC 

NSA 

Me**age  Security  Protocol  (MSP) 

SDN.701.  v.  4.0, 
Rev.  A:  1997 

Emerging 

(Approved) 

OPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701.  Rev.  3.0: 
1994 

Legacy 

(Approved) 

111111 

'  'MmwmmI 
■rjntft) 

lliilil 

os  iSi 

3.7.9.8.2  Alternative  specifications.  There  are  no  alternative  specifications. 


3.7.9.S.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown.  FIPS 
PUB  179-1  supersedes  FIPS  PUB  179. 
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3.7.9.8.4  Portability  caveats.  Proposed  security  enhancements  to  FT  AM  (WDAM4  to  ISO 
8571)  has  ceased.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3.7.9.8.5  Related  standards.  NCSC-TG-005,  Version  1 .  July  1987,  Trusted  Network 
Interpretation,  and  NCSC-TG-01 1,  Version  1,  August  1990,  Trusted  Networks  Interpretation 
Environments  Guideline  -  Guideline  for  Applying  the  Trusted  Network  Interpretation,  supports 
the  DOD  5200.28-STD. 

3.7.9.8.6  Recommendations.  The  mandated  standards  are  recommended. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DOD 
Standardized  Profile  (DSP)  standard  will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP 
123  or  ACP  120,  Common  Security  Protocol,  when  the  revision  to  MSP  is  complete. 

SDN.701,  Rcv.3.0,  is  used  with  DMS,  Phase  1.  It  is  for  use  with  legacy  systems  only. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

The  work  on  File  Transfer,  Access,  and  Management  (FTAM)  security  (WDAM4  to  ISO  857 1 ) 
security  enhancements  has  been  suspended.  Procurements  requiring  access  control  for  FTAM  and 
transaction  processing  should  not  use  these  standards. 

IEEE  802.10b  is  for  use  with  legacy  LANs  only. 
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3.7.9.?  D?la  encryption  security.  (This  BSA  appears  in  part  5,  part  7,  put  10,  and  part  1 1.) 
Encryption  is  the  cryptographic  transformation  of  data  to  produce  cipher  t  >xt  Standards  for  data 
encryption  security  services  describe  services  such  as  definitions/algorithms,  modes  of  operation, 
and  guidelines  for  use  ior  those  systems  that  require  their  data  to  be  encrypted  using  data 
encryption  security  services.  None  of  these  standards  are  for  systems  processing  classified 
information. 

3.7.9.9.1  Standards.  Table  3.7-51  presents  standa  's  for  data  encryption  security. 


TABLE  3.7-51  Data  encryption  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Escrowed  Enciyption  Standard  (FES) 

FIPS  PUB  185: 
1994 

Mandated 

(An*oved) 

GPC 

NIST 

Data  Encryption  Standard  (DES)  (related  to  ANSI  X3.92- 
1981/R1987/R1993) 

FIPS  PUB  46- 
2:1993  (Reaffirmed 
until  1998) 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  /or  Implementation  and  using  the  NBS  Data 
Enciyption  Standard 

FIPS  PUB  74:1981 

Informational 

(Approved) 

GPC 

NIST 

Data  Encry  ption  Standard  (DES)  Modes  of  Operation 
(related  to  ANSI  X3.106-1983) 

FIPS  PUB  81:1980 

Informational 

(Approved) 

GPC 

NIST 

Security  requirement!  for  Cryptographic  Modules 

FIPS  PUB  140- 
1:1994 

Informional 

(Approved) 

IPC 

ISO 

Mode  .  Operation  for  3  64-Bit  Block  Cipher  Algorithm 
(Related  to  ANSI  X3.1G6) 

8372:1987 

Informational 

(Approved) 

NPC 

ANSI 

Data  Encryption  Algorithm 

X3.  92-1981 
(R1993) 

buOTnational 

(Approved) 

NPC 

ANSI 

Digital  Encryption  Algorithm  -  Modes  of  Operation 

X3. 106- 1983 
(R1990) 

Informational 

(ARiroved) 

NOT 

191  in  . 

3.7.9.9.2  Alternative  specifications.  The  only  other  available  specifications  aire  proprietary,  for 
example,  RSA. 

3.7.9.9.3  Standards  deficiencies.  Deficit  jies  in  the  existing  standards  are  unknown. 

3.7.9.9.4  Portability  caveats.  DES  applicauons  are  not  interoperable  with  non-DES  systems. 
Portability  problems  related  to  the  EES  are  unknown.  The  U.S.  controls  export  of  ci yptographic 
technologies,  products,  and  related  technologies  as  munitions.  On  October  1,  1996,  a  new  federal 
policy  allowing  U.S.  vendors  to  export  products  using  up  to  56-bit  encryption,  provided  the 
vendors  sign  an  agreement  to  make  their  56-bit  enciyption  technoicgies  key-recovery-compliant 
within  24  monuis. 

3.7 .9.9.5  Related  standards.  FIPS  PUB  1 13,  Computet  Data  Authentication,  is  related  to  DES 
security  mechanisms  and  ’heir  standards. 
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3.7.9 .9.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  18S,  EES, 
supports  lawful  authorized  access  to  the  keys  required  to  decipher  enciphered  information  for 
systems  requiring  strong  encryption  protection  of  sensitive  but  unclassified  information.  EES 
provides  stronger  protection  than  DES  against  unauthorized  access.  Devices  conforming  to  EES 
may  be  used  when  replacing  Type  n  and  Type  III  (DES)  encryption  devices  owned  by  the 
Government  Implementations  requiring  use  of  EES  should  require  conformance  with  FIPS  PUB 
140-1. 


On  2  January  1997,  NIST  announced  plans  to  develop  a  FTPS,  Advanced  Encryption  Standard, 
incorporating  an  advanced  encryption  algorithm  to  replace  DES  (FIPS  PUB  46-2). 
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3.7.9.10  Traffic  flow  confidentiality.  (This  BSA  appears  in  part  7  and  part  10.)  Traffic  flow 
confidentiality  is  a  "service  to  protect  against  unauthorized  traffic  analysis  (ISO  7498-2)  by 
concealing  presence,  absence,  amount,  direction,  and  frequency  of  traffic. 

3.7.9.10.1  Standards.  Table  3.7-52  presents  standards  for  traffic  flow  confidentiality. 


TABLE3j7^2_^rafQcflowconfidentia[it2Standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecyde) 

CJPC 

NSA 

Secure  Data  Network  Syatem  (SDNS)  Security  Protocol  3 

(SP3) 

SDN.30I,  Revitioa 
1.5: 1989 

Informational 

(Approved) 

tPC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

3.7.9.102  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.10_3  Standards  deficiencies.  There  are  no  mandated  standards  for  traffic  flow 
confidentiality. 

3.7.9.10.4  Portability  caveats.  Work  on  proposed  amendments  to  ISO  10026  has  ceased.  This 
is  a  high  portability  risk  area,  because  no  standards  exist 

3.7.9.10.5  Related  standards.  There  are  no  related  standards. 

3.7.9.10.6  Recommendations.  No  standards  are  recommended. 

SP3  is  the  basis  for  ISO  1 1577. 
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3.7.9.11  Network  integrity.  (This  BSA  appears  in  part  7  'id  part  10.)  Network  integrity 
ensures  that  data  is  not  altered  or  destroyed  in  an  unauthorized  manner  when  transmitted  across  a 
network. 

3.7.9.11.1  Standards.  Table  3.7-53  presents  standards  for  network  integrity. 


TABLE  3.7-53  Network  integrity  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mu 

GP c 

DOD 

Information  Technology  -  Defense  Standardized  Profiled 
AMHXn(D>-  Message  Handling  Sy  Menu  •  Messag e 
Security  Protocol  (MSP)  Parti  1-5 

MIL-STD-2045- 
18500:  1993 

Mandated 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.301,  Revirion 
1.5: 1989 

Mandated 

(Approved) 

NPC 

IEEE 

|ij|ygg|ggyj|| 

802. 10b:  1992 

Lei** 

(Approved) 

[PC 

ISO 

Transport  Layer  Security  Protocol  (TLSP)  (Include* 
Amendment  1) 

10736:1994 

Informational 

(Approved) 

[PC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

tPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Model*,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  •  Part  4:  Protecting 
Transfer  Syntax  Spedfiraiion 

11586-4:1994 

Informational 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Security  Protocol  4 
(SP4) 

SDN.401.Rev. 

1.3:1989 

Informational 

(Approved) 

GPC 

NSA 

Message  Sec* **Py  Protocol  (MSP) 

SDN.701.  v.  4.0. 
Rev.  A:  1997 

Emerging 

(Approved) 

3.7.9. 1 12  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.11.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.7.9.11.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.7.9. 1 1*5  Related  standards.  ITU-T  X.500:  1993  (same  as  ISO  9594-1),  Information 
Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Overview  of  Concepts,  Models, 
and  Services,  is  a  related  standard. 

3.7.9.1 1.6  Recommendations.  The  mandated  standards  are  recommended. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5,  1  August  1989.  MSP  is 
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under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

SP4  is  the  basis  for  ISO  10736. 

IEEE  802.10b  is  for  use  with  legacy  LANs  only. 
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Version  3.1 


(Approved) 


(Approved) 


3.7.9.12.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.7.9.12.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 


April  7,  1997 


Version  3. 1 


3.7.9.12  Systems  non-repudiation.  (This  BS A  appears  in  part  S,  part  7,  part  10,  and  part  1 1 .) 
These  standards  provide  the  security  services  for  non-repudiation  in  systems. 

3.7.9.12.1  Standards.  Table  3.7-54  presents  standards  for  systems  non-repudiation. 

TABLE  3.7-54  Systems  non-repudiation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

DigiUl  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

GPC 

DOD 

Information  Technology  -  Defense  Standardized  Profile* 
AMHXn(D)-  Message  Handling  Systems  •  Message 
Security  Protocol  (MSP)  Part*  1-5 

MIL-STD-2045- 
18500:  1993 

GPC 

NSA 

Meetage  Security  Protocol  (MSP) 

SDN.701,Rev.  3.0: 
1994 

GPC 

NSA 

Menage  Security  Protocol  (MSP) 

SDN.701,  v.7.0, 
Rev.  A:  1997 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Model*,  and  Notation 

11586-1:1994 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  •  Part  4:  Protecting 
Tnrufer  Syntax  Specification 

11586-4:1994 

[PC 

ISO 

7498-2:1989 

LojKy 

(Approved) 


Emerging 

(Approved) 


Inform  »lionAl 
(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 
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3.7.9.12.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.7.9.12.5  Related  standards.  PIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.7.9.12.6  Recommendations.  The  mandated  standards  are  recommended  for  non-repudiation. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part.  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

MSP  provides  for  signed  receipts.  S/MIME,  an  Internet  Draft  specification,  does  not  provide  for 
signed  receipts. 
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3.7.9.13  Electronic  signature.  (This  BSA  appears  in  part  S,  part  7,  and  part  10.)  Electronic 
signature  is  the  process  that  operates  on  a  message  to  ensure  message  source  authenticity  and 
integrity,  and  source  non-repudiation.  Electronic  signatures  are  composed  so  that  the  identity  of  a 
signatory  and  integrity  of  the  data  can  be  verified. 

3.7.9.13.1  Standards.  Table  3.7-53  presents  standards  for  electronic  signature. 


TABLE  3.7-55  Electronic  signature  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

DigiUl  Signature  Standard  (DSS) 

FIPS  PUB 
146:1994 

Mandated 

(Approved) 

IPC 

ISO 

Digital  Signature  Scheme  Giving  Meuage  Recovery 

9796:1991 

Informational 

(Approved) 

3.7.9.13.2  Alternative  specifications.  Rivest-Shamir-Adelman  (RSA)  Public  Key  Algorithm 
RC-5  was  developed  and  published  in  1994.  It  is  proprietary,  but  RSA  Data  Security  is  working 
to  have  it  included  in  numerous  Internet  standards.  At  present,  RC-5  is  not  recommended  for 
DOD  use  because  it  is  proprietary. 

3.7.9.13.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.7.9.13.4  Portability  caveats.  DSS  applications  are  not  interoperable  with  non-DSS  systems. 

3.7.9.13.5  Related  standards.  FIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.7.9.13.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  186  is 
implemented  in  the  FORTEZZA  cryptographic  card,  a  PC  card  (formerly  called  a  Personal 
Computer  Memory  Card  International  Association  (PCMCIA)  standard  card)  that  can  be 
integrated  into  personal  computers  and  workstations  to  provide  security  in  commercial 
applications.  FORTEZZA  is  being  used  in  the  Defense  Message  System.  FIPS  PUB  186  is  the 
government-wide  key  cryptographic  signature  system. 
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3.7.9.14  Electronic  hashing.  (This  BSA  appears  in  part  S,  part  7,  part  8,  and  part  10.) 
Electronic  hashing  services  compute  a  condensed  representation  of  a  message  or  a  data  file,  often 
used  as  a  measure  of  data  integrity  checking. 

3.7.9.14.1  Standards.  Table  3.7-S6  presents  standards  for  electronic  hashing. 


TABLE  3.7-56  Electronic  hashing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Secur*  Huh  Standard  (SHS) 

FIPS  PUB  180- 
1:1995 

Mandated 

(Approved) 

[PC 

ISO 

Huh  Functions,  Put  1:  General  Model 

10118-1:1994 

Informational 

(Approved) 

[PC 

ISO 

Huh  Function*,  Part  2:  Huh  Function*  Uiing  an  N-Bit 
Block  Cipher  Algorithm 

10118-2:1994 

Informational 

(Approved) 

'  5 

v  WM 

•  /  '  . 

3.7.9.14.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.7.9.14.3  Standards  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.7.9.14.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.7.9. 14.5  Related  standards.  FIPS  PUB  180-1  supersedes  FIPS  PUB  180  and  is  required  for 
use  with  FIPS  PUB  186,  Digital  Signature  Standard. 

3.7.9.14.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  180-1 
specifies  SHA,  which  can  be  used  to  generate  a  message  digest.  SHA  is  required  for  use  with  the 
DSA  as  specified  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  for  federal  applications. 
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3.7.9.15  Data  communications  security  labeling.  (This  BSA  appears  in  part  7  and  part  10.) 
Data  communications  security  labeling  encompasses  the  application  of  security  labeling,  which  is 
used  as  the  basis  for  mandatory  access  control  security  services  and  release  security  services. 

3.7.9.15.1  Standards.  Table  3.7-57  presents  standards  for  data  communications  security 
labeling. 


TABLE  3.7-S7  Data  communications  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pgm 

GPC 

DOD 

Common  Security  Label  (CSL) 

MIL-STD-2045- 
48501:  1995 

Mandated 

(Approved) 

IPC 

ISO 

Transport  Layer  Security  Protocol  (TLSP)  (Include* 
Amendment  1) 

10736:1994 

InfoimationaJ 

(Approved) 

IPC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

IPC 

ISO 

OSI  Baiic  Reference  Model,  Part  2:  Security  Architecture 
(*ame  a*  CCITT  X. 800:1991) 

7498-2:1989 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

mm 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  liter  Interface 
Guideline*,  Revirion  1 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compartmenled  Mode  Workitarion  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

GPC 

NIST 

Standard  Security  Label  (SSL)  for  Information  Transfer 

FIPS  PUB 
188:1994 

Informational 

(Approved) 

MM  »  iff?  < »  Jp 

S'-'  /  1  !  \  .  -  • 

v  .....  ..  ..  •  ■ .. 

'l  l '—i  -  ^ 

3.7.9.15.2  Alternative  specifications.  There  are  no  altem  ive  specifications. 

3.7.9.15.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.7.9.15.4  Portability  caveats.  Portability  problems  related  to  the  existing  standards  are 
unknown. 

3.7.9.15.5  Related  standards.  DOD  5200.28-STD  is  a  related  standard.  DOD  5200. 1-R. 
"Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy  for  security 
classification,  declassification,  and  marking  of  DOD  information.  It  also  contains  DOD  policy  for 
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safeguarding  of  classified  information,  including  accountability,  storage,  transmission,  and 
destruction  of  the  information. 

3.7.9.15.6  Recommendations.  The  mandated  standard  is  recommended  and  should  be  used  for 
new  acquisitions.  MIL-STD-2045-48501  supports  the  exchange  of  security  attributes,  for 
example,  sensitivity  labels.  It  provides  a  means  to  label  and  protect  data  as  it  passes  through 
communications  systems  and  implements  PIPS  PUB  188  for  the  DOD  environment.  MIL-STD- 
2045-48501  and  FIPS  PUB  188  apply  only  to  layers  3  and  4.  TSIG  TSIX(RE)  1.1,  "Trusted 
Systems  Interoperability  Group,  Trusted  Security  Information  Exchange  for  Restricted 
Environments,"  includes  options  compatible  with  MIL-STD-2045-48501. 

IEEE  802.  lOg  is  consistent  with  the  SSL  and  the  CSL. 

RFC  1 108  makes  RFC  1038  obsolete.  RFC  1 108  should  be  used  for  legacy  systems  only.  RFC 
1038  is  not  recommended. 
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Acronym  List 


Acronyms.  The  acronyms  used  in  Part  7  are  defined  as  follows: 


AAL 

ACP 

AD  PCM 

AF 

AITS 

AJ 

ALE 

ANSI 

ARID  PCM 

ARP 

ATDL-1 

ATM 


ATM  adaptation  layer 
Atied  Communication  Publication 
adaptive  differential  pulse-code  modulation 
ATM  Forum 

Adopted  Information  Technology  Standard 
anti-jam 

automatic  link  establishment 

American  National  Standards  Institute 

Adaptive  Recursive  Interpolated  Differential  PCM 

Address  Resolution  Protocol 

Army  Tactical  Data  Link  1 

asynchronous  transfer  mode 


B-Channel  bearer  channel 

BER  bit  error  ratio 

B-ISDN  broadband-tSDN 

BOOTP  BOOTSTRAP  protocol 

bps  bit  per  second 


CDMA 

CELP 

CJCSM 

CNR 

CONS 

CPC 

CPN-C 

CSMA/CD 

CVSD 

C4I 


code-division  multiple  access 
code-excited  linear  prediction 
Chairman  of  the  Joint  Chiefs  of  Staff  Manual 
combat  net  radio 

connection-oriented  network  service 
Consortia  Public  Consensus 
Corporate  Private  Non-Consensus 
carrier  sense  multiple  access/collision  detection 
continuously  variable  slope  delta 

command,  control,  communications,  computers,  and  intelligence 


DAMA 

D-channel 

DCE 

DEC 

DHCP 

DMS 

DoD 

DSN 

DS1 

DS3 


demand-assignment  multiple  access 

16-  or  64-kbps  channel  for  signaling  and  data 

data  circuit-terminating  equipment 

Digital  Equipment  Corporation 

Dynamic  Host  Configuration  Protocol 

Defense  Message  System 

Department  of  Defense 

Defense  Switched  Network 

Digital  Interface  Rate  1  (1.544  Mbps) 

Digital  Interface  Rate  3  (44.736  Mbps) 
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DSS1 

DSS2 

DTE 


Digital  Subscriber  Signaling  System  Number  1 
Digital  Subscriber  Signaling  System  Number  2 
data  terminal  equipment 


EHF 

extremely  high  frequency 

EIA 

Electronic  Industries  Association 

FDDI 

Fiber  Distributed  Data  Interface 

FDMA 

frequency-division  multiple  access 

FED-STD 

federal  standard 

FPLMTS 

future  public  land  mobile  telecommunications  system 

FIPS 

Federal  Information  Processing  Standard 

FT  AM 

file  transfer,  access,  and  management 

FTP 

File  Transfer  Protocol 

GPC 

Government  Public  Consensus 

HDLC 

high-level  data  link  control 

HF 

high  frequency 

IAB 

Internet  Architecture  Board 

ICMP 

Internet  Control  Message  Protocol 

IEC 

International  Electrotechnical  Commission 

IEEE 

Institute  of  Electrical  and  Electronics  Engineers 

IESS 

Intelsat  Earth  Station  Standard 

IETF 

Internet  Engineering  Task  Force 

IGMP 

Internet  Group  Management  Protocol 

IP 

internet  protocol 

IPC 

International  Public  Consensus 

ISDN 

Integrated  Services  Digital  Network 

ISO 

International  Organization  for  Standardization 

ISUP 

ISDN  User  Part 

ITSG 

Information  Transfer  Standards  Guidance 

ITU 

International  Telecommunications  Union 

ITU-T 

ITU -Telecommunication  Standardization  Sector  (formerly  CCITT) 

JTA 

Joint  Technical  Architecture 

JTIDS 

Joint  Tactical  Information  Distribution  System 

kbps 

kilobit  per  second 

kHz 

kilohertz 

LAN 

local  area  network 

LAP 

link  access  protocol 

LAPB 

LAP  balanced 
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LAPD 

LAP  on  the  D-channei 

LF 

low  frequency 

LLC 

logical  link  control 

LOS 

line-of-sight 

LPC 

linear  predictive  coding 

Mbps 

megabit  per  second 

MF 

medium  frequency 

MIB 

management  information  base 

MIL-STD 

military  standard 

MLPP 

Multi-level  Precedence  and  Preemption 

MSE 

Mobile  Subscriber  Equipment 

MSP 

message  security  protocol 

MSR 

message  storage  and  retrieval 

MTP 

message  transfer  part 

NATO 

North  Atlantic  Treaty  Organization 

N-ISDN 

narrowband  ISDN 

NIST 

National  Institute  of  Standards  and  Technology 

NITF 

National  Imagery  Transmission  Format 

NITFS 

NITF  standard 

NNI 

network-node  interface 

NPC 

National  Public  Consensus 

NRI 

net  radio  interface 

NRZ 

non-return-to-zero 

NSA 

National  Security  Agency 

OSI 

Open  Systems  Interconnection 

PCM 

pulse-code  modulation 

PCS 

personal  communications  services 

PICS 

protocol  implementation  conformance  statement 

PNNI 

private  node  network  interface 

PPP 

point-to-point  protocol 

PVC 

permanent  virtual  circuit 

QPSK 

quadrature  phase  shift  keying 

if 

radio  frequency 

RFC 

request  for  comment 

SCCP 

signaling  connection  control  part 

SHF 

super  high  frequency 

SINCGARS 

Single-Channel  Ground  and  Airborne  Radio  System 

SMDS 

switched  multi-megabit  data  service 
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SMTP 

Simple  Mail  Transfer  Protocol 

SNMP 

Simple  Network  Management  Protocol 

SONET 

synchronous  optical  network 

SS7 

Signaling  System  Number  7 

STAN.  .G 

standardization  agreement 

STU 

secure  telephone  unit 

SVC 

switched  virtual  circuit 

TAC02 

Tactical  Communications  Protocol  2 

TADIL 

tactical  digital  information  link 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TCP 

transmission  control  protocol 

TDM 

time-division  multiplexing 

TDMA 

time-division  multiple  access 

TIA 

Telecommunications  Industry  Association 

TOS 

typ ;  of  service 

TPO 

transport  protocol  class  0 

TRI-TAC 

Tri-Service  Tactical  Communications 

UDP 

user  datagram  protocol 

UHF 

ultra  high  frequency 

UNI 

user-to-network  interface 

UPT 

universal  personnel  telecommunications 

URL 

uniform  resource  locator 

UTC 

coordinated  universal  time 

VHF 

very  high  frequency 

VMF 

variable  message  format 

VTC 

video  teleconferencing 

WNDP 

worldwide  numbering  and  dialing  plan 

XID 

exchange  identification 
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Index  of  Standards 

Standard  Page 

ACP  123  US  Supplement  No.l . 4,  5 

ACPI  27 . 21 

AF  LANE  v  1.0 . 44 

AF  PNNIvl.O . 44 

AF  UNI  v3. 1 . 44 

AF-PHY-0015.00 . 68 

AF-PHY-00 16.00 . 68 

AF-PHY-0018.00 . 8 

ANSI/IEEE  802.  IB . 29 

ANSI  J-STD-008 . 56,  57 

ANSI  J-STD-009 . 56 

ANSI  J-STD-010 . 56 

ANSI  J-STD-01 1 . 56 

ANSI  Tl. 101 . 51 

ANSI  Tl.  105 . 70 

ANSI  Tl.  106 . 68 

ANSI  Tl.  107 . 70 

ANSI  Tl. Ill . 37,  38 

ANSI  Tl. 112 . 37,38 

ANSI  Tl. 113 . 37,  38 

ANSI  Tl. 114 . 37,  38 

ANSI  Tl. 117 . 68 

ANSI  Tl. 119 . 69 

ANSI  T1.219 . 38 

ANSI  Tl. 234 . 38 

ANSI  T1.236 . 38 

ANSI  T1.239 . 38 

ANSI  T1.302 . 23 

ANSI  T1.310 . 23 

ANSI  T1.314 . 14 

ANSI  T1.408 . 37,  38 

ANSI  T1.501 . 23 

ANSI  T1.601  . 37,38 

ANSI  Tl. 603 . 38 

ANSI  T  1.604 . 38 

ANSI  Tl. 605 . . . 37,  38 

ANSI  Tl. 608 . 37,38 

ANSI  Tl. 609 . 37,38,  55 

ANSI  Tl .610 . 40 

ANSI  T1.613 . 40,  42 
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ANSI  T1.616 . 40,42 

ANSI  T1.617 . 54,  55 

ANSI  T1.618 . 31,32,  54,  55 

ANSI  T1.619 . 40,41 

ANSI  T1.621 . 40,42 

ANSI  T1.622 . 40,43 

ANSI  T1.625  . 40,42 

ANSI  T1.627  . 44,46 

ANSI  T1.629 . 44,46 

ANSI  T1.630  . 44,46 

ANSI  T1.632  . 40,42 

ANSI  T1.633 . 54,55 

ANSI  T1.634 . 54,  55 

ANSI  Tl. 635 . 44,46 

ANSI  T1.636  . 45 

ANSI  T  1.637  . 44,46 

ANSI  Tl. 638  . 45 

ANSI  T  1.642  .  40,  43 

ANSI  T1.643  .  40,  43 

ANSI  T1.645 . 45 

ANSI  T  1.647  .  40,  42 

ANSI  T  1.653  . 40, 43 

ANSI  Tl. 656 . 55 

ANSI  Tl. 801.01 . 14 

ANSI  X3. 106 . 104 

ANSI  X3.229 . 29,  30 

ANSI  X3.92 . 104 

ANSI  X9.17 . 94 

Bellcore  TR-TS V-00772 . 3 1 ,  32 

CCEB  CC  version  1.0 . 96 

CJSM6231 .  72,73 

CSC-STD-003-85 . 89 

CSC-STD-004-85 . 89 

DCAC  370-175-13 . 37,39 

DCE  1.1  Security . 90 

DCE  Rev.  1.2.2 . 90 

DEC  DDCMP . 21 

DOD  5200.28-STD . 87,  89,  90,  96,  1 13 

DOD  DDS-2600-62 16-91 . 113 

DOD  DDS-2600-6243-9 1 . 113 

DOD  DDS-2600-6243-92 . 113 

DOD  FORTEZZA  ICD  Rev  P1.5 . 99 

DOD  FORTEZZA  Plus  ICD  Rel  3.0 . 99 

DOD  NCSC-TG-001,  version  2 . 96 

DOD  NCSC-TG-005 . 87,  90,  96,  99,  103 
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DOD  NCSC-TG-01 1 . 88, 96, 100, 103 

DOD  NCSC-TG-021 . 90 

EIA-232E . 34 

EIA-449 . 34 

EIA-530A . 34 

EIA/TIA-465-A . 16 

EIA/ITA-466-A . 16,  82 

EIA/TIA 1S-41-C . 56,  57 

ELA/TIA  1S-54-B . 56,  57 

EIA/TIA  IS-95-A . 56,  57 

EIA  TIA/IS-98 . 57 

EIA/TIA  IS- 136 . 56 

E1ATSB47 . 57 

EIATSB51 . 57 

EIA  TSB56-A . 57 

EIA  TSB64 IS-41-B . 57 

FED-STD-1002  . 51 

FED-STD-1015 . . . 23,  24, 47, 49,  50 

FED-STD-1016 . 23,  24, 49,  50 

FED-STD-1047 . 65,  66 

FED-STD-1048 . 65,  66 

FED-STD-1055 . 65,  66 

FED-STD-1056 . 65,66 

FED-STD-1057 . 65,  66 

FIPS  PUB  31 . 89 

FIPS  PUB  46-2 . 104 

FIPS  PUB  65 . 89 

FIPS  PUB  74 . 104 

FIPS  PUB  81 . 104 

FIPS  PUB  83 . 102 

FIPS  PUB  113 . 104 

FIPS  PUB  140-1 . 104 

FIPS  PUB  171 . 94 

FIPS  PUB  178 . 14 

FIPS  PUB  178-1 . ’4,  15 

FIPS  PUB  179 . 91,98,  100,  102 

FIPS-PUB-179-1  .  52,  53,90,98,  100,  102 

FIPS  PUB  180 .  100,  1 12 

FIPS  PUB  180-1 .  100,  109,  111,  112 

FIPS-PUB-182 . 37,  38 

FIPS  PUB  185 .  104 

FIPS  PUB  186 . 99,  107,  111,  112 

FIPS  PUB  188 . 113 

FIPS  PUB  191 . 89 

FIPS  PUB  JJJ . 104 
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FRF.5 . 54,  55 

FRF.8 . 54,  55 

IAB  STD-3 . 2, 4, 7,  35 

LAB-STD-5 . 2, 7,  8, 25,  26 

IAB-STD-6 . 2,  7,  8,  25,  26 

IAB-STD-7 . 2,  7,8,25,26 

IAB-STD-8 . 2, 4,  25,26 

IAB-STD-9 . 2,  4 

IAB-STD-10 . 5 

IAB-STD-13 . 2,  10,  11,25,  26 

IAB-STD-15 . 2,  12,  13,  25,  26 

IAB-STD-16 . 3,  12,  13,  25,  26 

LAB-STD-17 . 3,  12,  13,  25,  26 

LAB-STD-27 . 5 

IAB-STD-28 . 5 

IAB-STD-32 . 5 

1AB-STD-33 . 3,  25,  26 

IAB-STD-35 . 3,7,8,80 

IAB-STD-36 . 54,  55 

IAB-STD-37 . 3,28,  30 

IAB-STD  38 . 3,28 

IAB-STD-41 . 3,  28,30,  54,55 

IAB-STD-43 . 3,  54,55 

IAB-STD-5 1 . 3,33,  34 

IEC  847 . 29 

IEEE  802.3u . 28,  30 

IEEE  802.10a . 87 

IEEE  802. 10b . 99,  102,  107 

IEEE  802.10c . 94 

IEEE  802.  lOd . 91 

IEEE  802.10g/D7 . 113 

IEEE  802.11  . 28,30 

IEEE  P1003.1e . 91 

IEEE  PI 003. 2c . 91 

IEEE  PI 363 . 64 

IESS  308  . 63 

IESS  309 . 63 

IETF  draft-dussc-mime-msg-spec-OO.txt . 100,  104 

IETF  draft-frier-ssl-version  3-01.txt . 100 

IETF  draft-ietf-ipsc-oakley-0 1  .txt . 94 

IETF  draft-ietf-ipsec-isakmp-05.txt,.ps . 94 

IETF  draft-ietf-ipssec-arch-sec-01.txt . 87 

IETF  draft-ietf-ipssec-skip-06.txt . 94 

IETF  draft-simpson-photuris-10.txt . 94 
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ISO  3309 . 19 

ISO  4335 . 19 

ISO  7498-2  .  87,  90,  109, 113 

ISO  7498-4  . 52 

ISO  7776 .  19 

ISO  7809 . 19 

ISO  8073 . 7,  8 

ISO  8208 . 7,  8 

ISO  8372 . 104 

ISO  8471 . 19 

ISO  8473-2 . 29 

ISO  8571-1,2,3,4:1988/  WDAM4:1993 . 100,  102 

ISO  8649  . 99 

ISO  8650 . 99 

ISO  8732 . 94 

ISO  8802-2 . 28,  29,  35 

ISO  8802-3 . 28,29 

ISO  8802-4 . 28,  29 

ISO  8802-5 . 28,29 

ISO  8878 . 7,  8,31 

ISO  8881  . 31 

ISO  8885 . 19,  35 

ISO  93 14 . 28,  29 

ISO  9595 . 53 

ISO  9596-1 . 53 

ISO  9796 . Ill 

ISO  10118-1 . 112 

ISO  10118-2 . 112 

ISO  10165-1 . 52 

ISO  10165-2 . 52 

ISO  10165-4 . 52 

ISO  10181-2 . 100 

ISO  10588 . 31 

ISO  10736 . 99,  102,  107,  113 

ISO  10745 . 87 

ISO  11577 . 99,  102,  106,  107,  113 

ISO  11586-1 . 87,  94,  104,  107,  109 

ISO  11586-2 . 94,  100 

ISO  11586-3 . 94,  100 

ISO  11586-4 . 100,  107,  109 

ISO  13888-1:1992  (SC27  N868  (Project  1.27.06.01)) . 109 

ISO  13888-2:1994  (SC27  N864  (Project  1.27,06.02)) . 109 

ISO  13888-3:1992  (SC27  N869  (Project  1.27,06.03)) . 109 

ISO  DIS  10165-7 . 53 

ISO  ISP  10608-4 . 29 
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ISO  ISP  10608-6 . 29 

ISO  ISP  10609-11 . 29 

ISO  SC27/WG2  N294  (Project  1 .27.08.0 1 ) . Ill 

ISO  SC27/WG2  N295  (Project  1.27.08.02) . 1 1 1 

ISO  SC27/WG2  N296  (Project  1.27.08.03) . 1 1 1 

ISOTR  10178 . 29 

ISO  WD  10118-3,  JTC1/SC27  N883  (Proiect  1.27.09.03) . 1 12 

ISO  WD  101 18-4,  JTC1/SC27N884  (Project  1.27.09.04) . 112 

ISO  WDAMs  (SC21  N  5232  to  ISO  10026-1 ,2,3) . 106,  109 

ISO/IEC  9594-1,2,3,4:1990/ DAM1 . 102 

ISO/IEC  9594-8: 1 990/  DAM  1 . 1 02 

ISO/IEC  9595: 1991/ AM4: 1992 . 52,  90,  102 

ISO/IEC  9596-1 . 52,90 

ISO/IEC  10164-7 . 90,  98 

ISO/IEC  10164-8 . 90,96 

ISO/IEC  10164-9 . 90 

ISO/IEC  10181-1 . 87 

ISO/IEC  10181-2 . 87,  100 

ISO/IEC  10181-3 . 87 

ISO/IEC  10181-4 . 88,  109 

ISO/IEC  10181-5 . 88 

ISO/IEC  10181-6 . 88 

ISO/IEC  10181-7 . 88,  96 

ISO/IEC  10181-8 . 88,  94 

ISO/IEC  JTC1/SC21  SD-7 . 91 

ISO/IEC  TR  13594 . 87 

ISO/IEC  WDAMs  ((SC21  N6232)  to  ISO  10026-1,2,3) . 96 

ITU-T  E.163 . 37,  39 

ITU-T  E.164 . 37,  39 

ITU-T  E.  168 . 60 

ITU-T  E.  173 . 59 

ITU-T  E.  175 . 60 

ITU-T  E.201 . 59 

ITU-T  E.202 . 59 

ITU-T  E.2 12 . 59 

ITU-T  E.220 . 59 

ITU-T  E.751 . 58 

ITU-T  E.771 . 58 

ITU-T  E.775 . 60 

ITU-T  E.776 . 60 

ITU-T  E.780 . 58 

ITU-T  F.  115 . 59 

ITU-T  F.724 . 58 

ITU-T  F.850 . 60 

ITU-T  F.851 . 60 
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ITU-T  F.852 . 

ITU-T  F.853 . 

ITU-T  FPLMTS.FMGM .... 
ITU-T  FPLMTS.SECMOP 

ITU-T  FPLMTS.SFMK . 

ITU-T  G.703 . 

ITU-T  G.704 . 

ITU-T  G.7 11 . 

ITU-T  G.712 . 

ITU-T  G.721 . 

ITU-T  G.728 . 

ITU-T  G.782 . 
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3.8  Operating  system  services.  Operating  system  services  are  the  core  services  needed  to 
operate  and  administer  the  application  platform  and  provide  functions  for  which  application 
software  can  access  the  platform.  Application  programmers  will  use  operating  system  services  to 
obtain  operating  system  functionality.  However,  implementors  of  other  services  may  bypass  the 
operating  system  to  obtain  functionality.  Operating  system  services  include  kernel  operations, 
commands,  utilities,  system  management,  and  system  security.  Throughout  section  3.8, 
references  to  IEEE  1003.n,  1003.n,  and  POSIX.n  indicate  the  same  standard  and  will  be  used 
interchangeably. 

NOTE:  Throughout  Part  8,  all  tables  have  abbreviations  listed  under  the  column  (Standard  Type) 
as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  IPC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Consortia  Private  Non-Consensus  =  CPN-C 

f.  National  Public  Non-Consensus  =  NPN-C 

g.  Publicly  Available  Specifications  =  PAS 

3.8.1  Kernel  operations.  Basic  kernel  services  are  system  services  that  run  the  hardware.  They 
provide  a  virtual  machine  for  the  user  and  programmer  and  are  resident  in  memory.  Kernel 
operations  provide  low-level  services  necessary  to  create  and  manage  processes,  execute 
programs,  define  and  communicate  signals,  define  and  process  system  clock  operations,  manage 
files  and  directories,  and  control  input  and  output  processing  to  and  from  peripheral  devices. 

3.8. 1.1  Process  management  and  core  operating  system  services.  (This  BSA  appears  in  both 
part  8  and  part  9.)  Core  operating  system  services  are  basic  operating  system  services  and 
interfaces,  including  traditional  process  management,  memory  management,  time  services, 
schedule,.,  terminal  handling,  error  and  exception  management  services,  file-oriented  services, 
and  generalized  input  and  output. 

3.8.1. 1.1  Standards.  Table  3.8-1  presents  standards  for  process  management  and  core  operating 
system  services. 


TABLE  3.8-1  Process  management  and  core  operating  system  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  Syatem  Interface  (1’QSIX)  Part  ! : 
System  API  (Replaces  ISO  9945- 1 ;  1990  and  incorporates 
IEEE  1003.1b,  1003.1c.  and  1003.1i) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmers'  Reference 
Manual,  1993.  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

X/Open 

Single  UNIX  Specification.  System  Interface  Definitions. 
Vernon  2,  Issue  5 

C605  (2/97) 

Emerging 

(Approved) 
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Standard  Sponsor 
Type 


Standard 

Reference 


Standard 


CPC 


X/0p« 


Single  UNIX  Specification,  System  Interface*  and  Headers 
Version  2.  Iuue  5 


C606  (2/97) 


1003.  Ib:  1993 


NPC 


1HHH 


Portable  Operating  System  Interface  (POSIX)  •  Part  1: 
System  Application  Program  Interface  (API)  Amencfcnent 
1 :  Realtime  Extension  (C  language) 


POSIX  Part  1 :  System  Application  Program  Interface 
(API)  Amendnent  2:  Threads  Extension  (C  Language) 


Infonnabonal 

(Approved) 


NPC 


1003.1c:  1995 


1003.  ti:1995 


2003.1:1992 


1003.10:1995 


Informational 

(Approved) 


NPC 


IFFF. 


POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  (C  Language] 


Test  Methods  for  Measuring  Conformance  to  POSIX  - 
System  Interfaces 


Informational 

(Approved) 


NPC 


n.U. 


Informational 

(Approved) 


Informational 

(Approved) 


NPC 


GPC 


NIST 


Informational 

(Approved) 


3.8.1. 1.2  Alternative  specifications.  Other  consortia  or  de  facto  alternative  specifications  (such 
as  ECMA  APIW)  for  the  Portable  Operating  System  Interface  for  Computer  Environments 
(POSEX)  standard  PI 003.1  are  available. 

3.8.1. 1.3  Standards  deficiencies.  ISO  9945-1: 1996  incorporated  IEEE  1003.1b  Realtime  and 
IEEE  1003.  lc  Threads.  This  resolves  some  of  the  deficiencies  in  the  original  POSIX.  1 ,  but  the 
following  deficiencies  remain  in  the  available  standards: 

a.  Lacks  batch  scheduling  for  distributed  computing. 

b.  Has  weak  event,  error,  and  exception  management  services. 


April  7,  1997 


3.8-2 


Version  3. 1 


Information  Technology  Standards  Ouidanci 


Operating  System  Services 


c.  Has  weak  or  no  generalized  VO  device  driver  services. 

d.  Has  reentry  problems  when  used  for  multiprocessing. 

e.  Reliability  and  maintainability  not  reflected  in  the  standard. 

f.  The  tasking  model  on  which  Ada  is  based  does  not  map  well  to  the  process  model 
on  which  POSIX.l  is  based. 

g.  Has  tape  handling  facilities  requiring  long  backup  times. 

3.8. 1.1.4  Portability  caveats.  Different  specifications  and  implementations  conforming  with 
POSIX  (e.g.,  OSF/1,  SVID,  SVR4,  X/Open,  and  vendor  products)  often  support  the  same 
function,  but  support  them  slightly  differently.  For  example,  the  names  of  system  calls  may  be 
identical,  but  unanticipated  incompatibilities  will  arise  because  of  differences  in  the  data  types  of 
the  function,  the  data  types  of  the  arguments,  the  return  values,  the  required  header  files,  and  the 
symbolic  error  values. 

Implementations  conforming  with  POSIX  may  require  extra  header  files  for  function  calls  that  are 
ported  from  a  system  not  requiring  header  files  to  another  requiring  header  files.  Although  the 
impact  of  requiring  extra  header  files  is  not  always  clear,  differences  in  header  file  requirements 
can  reduce  portability.  For  example,  if  a  program  is  ported  from  a  system  not  requiring  a  header 
file  for  a  particular  function  call,  to  a  system  requiring  it,  the  call  to  that  function  may  be 
undefined  and  generate  an  error  message  about  the  nonexistent  header  file. 

Differences  within  header  files  can  reduce  portability  when  moving  from  a  system  that  does  not 
require  a  header  file  to  one  that  does.  For  example,  a  header  file  may  define  attributes  like  data 
types  or  symbols  conflicting  with  locally  defined  symbols. 

Implementations  of  systems  conforming  with  POSIX  may  refer  to  devices  by  logical  names, 
numeric  indicators,  data  structures,  or  pointers.  Superset  functions  in  implementations 
conforming  with  POSIX  are  important  to  have  and  convenient  to  use,  but  they  reduce  portability. 

The  meaning  of  ownership  of  "symbolic  links"  is  not  clear  or  consistent  across  different  systems. 
Only  the  meaning  of  owning  a  file  is  consistent. 

Many  system  attributes,  such  as  system  limits  and  configuration  values  limits,  are  defined  by 
implementation. 

3.8.1. 1.5  Related  standards.  The  following  standards  are  related  to  process  management  and 
core  operating  system  services  or  their  standards: 

a.  IEEE  1003.2: 1992:  POSIX  -  Shell  and  Utilities. 

b.  IEEE  1003.2a:  1992:  POSIX  -  User  Portability  Extension. 

c.  IEEE  P1003.1e:  POSIX  -  Security  Interface  Extensions. 
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d.  IEEE  P1003.21:  POSIX  -  Real  Time  Distributed  Systems  Communications. 

e.  X/Open  Common  Desktop  Environment  (XCDE)  -  Definitions  and  Infrastructure. 

3.8.1. 1.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:1995,  and  IEEE  1003.  li:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  IEEE  1003.1b  (section  3)  standardized  additional  functions  not  in  9945-1:1990  such  as 
memory  management  and  clocks  and  timers.  Federal  Information  Processing  Standard  (FIPS) 
151-2  should  also  be  consulted.  It  adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996 
version.  It  specifies  many  of  the  implementation-defined  system  limits  related  to  files  and 
directories  and  input/output. 

To  ensure  maximum  portability  and  smooth  running  information  processing  functions,  it  is 
important  to  determine,  at  a  detailed  level  (e.g.,  arguments,  order  of  the  arguments,  data  types  of 
the  function  and  arguments,  return  values,  symbolic  error  numbers),  the  specific  areas  of 
incompatibility  between  POSIX  and  the  systems  bid  by  vendors. 

To  ensure  that  no  harm  will  result  if  an  application  is  ported  from  a  system  that  requires  and 
supports  a  header  file  to  a  system  that  does  not  require  the  "include"  statement  in  the  system  call, 
remove  the  header  file  from  the  application. 

Avoid  the  use  of  extensions  to  POSIX  However,  if  extensions  to  POSIX  must  be  used  (they  may 
be  convenient),  the  applications  in  which  they  are  used  must  be  designed  carefully  for  portability 
(e.g.,  separate  the  portable  from  the  nonportable  code,  carefully  document  all  nonportable  code). 

Including  those  header  files  required  by  POSIX.  1  will  er  .are  that  properly  written  programs  will 
build  successfully  on  all  FIPS-certified  POSIX.  1 ,  regardless  of  which  header  files  may  be  optional 
on  a  given  vendor’s  platform. 

Specifying  that  systems  must  conform  to  the  X/Open's  Single  Unix  Specification  as  demonstrated 
by  a  current  X/Open  Branding  Certificate  will  eliminate  the  portability  problems  identified  in  the 
first  paragraph  of  the  portability  caveats  section. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes;  interfaces  previously 
defined  in  the  ISO  POSDC.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8. 1.2  File  management  services.  File  management  is  the  system  of  rules  and  policies  for 
maintaining  a  set  of  files  including  how  files  can  be  created,  accessed,  retrieved,  and  deleted.  The 
application  program  interfaces  provide  a  vehicle  for  an  application  program  to  access  and  update 
a  file  whether  the  file  is  on  a  local  or  remote  system.  Commands  and  protocols  required  to  access 
remote  files  are  covered  by  the  Distributed  File  Services  BSA. 

3.8.1.2.1  Standards.  Table  3.8-2  presents  standards  for  file  management  services. 


TABLE  3.8-2  File  management  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hi 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  1 : 
Syitem  API  (Replace*  ISO  9945- 1 : 1990  and  incorporate! 
IEEE  1003.1b,  1003.1c,  and  1003.!i) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Micro  *oft 

Window  Management  and  Graphics  Device  Interface, 
Voliane  I  Microsoft  Win32  Programmer*’  Reference 
Manual,  1993,  Microsoft  Preai 

Win32  API* 

Mandated 

(Approved) 

CPC 

X/Opm 

Single  UNIX  Specification,  System  Interface*  and  Header*. 
Vereion  2,  luue  S 

C606  (2/97) 

Emerging 

(Approved) 

NPC 

IEEE 

Portable  Operating  Syitem  Interface  (POSIX)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Information*! 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  Syitem  Application  Program  Interface 
(API)  -  Amend:  Tedtnical  Corrigenda  to  Real  Time 
Extension  [C  Language] 

1 003 . 1  i :  1 995 

Informational 

(Approved) 

GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  -  Syitem 
Application  Program  Interface/ C  Language  (adopt* 
ISO/IEC  9945-1:1990) 

PIPS  PUB  151- 

2:1993 

Informational 

(Approved) 

I  W: 
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_ _ _ 

— 

3.8. 1.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.274.3  Unix:  Unix  File  System  (UFS)  (Tahoe  fast  file  system). 

b.  Unix  COFF  file  format 

3.8.1.2.3  Standards  deficiencies.  POSIX  does  not  support  mandatory  file  locking  .  The 
advisory  locking  that  it  supports  instead  can  lead  to  accidental  file  access  collisions  and  corrupted 
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data,  unless  the  processes  using  the  advisory  locking  cooperate  and  use  the  advisory  mechanism 
before  doing  input  and  output  operations  on  the  file. 

POSDC.  1  lacks  the  "seekdir"  capability  (to  set  a  position  in  a  directory  stream)  and  the  "telldir" 
capability  (to  tell  a  position  in  the  directory  stream).  111656  are  popular  capabilities  supported  by 
X/Open,  and  System  V  Interface  Definition.  They  have  been  proposed  for  the  POSIX.la  revision. 

POSIX.  1  lacks  the  following  symbolic  link  capabilities:  "symlinkO"  to  make  a  symbolic  link, 
"teadlinkO  to  read  a  symbolic  link,  and  "IstatO  to  get  the  status  of  a  symbolic  link.  Symbolic  links 
are  important  because  they  allow  users  and  vendors  to  provide  backward  compatibility  and 
portability  for  applications,  without  requiring  changes  to  every  line  of  code  in  every  application 
that  refers  to  a  file  that  is  no  longer  in  a  particular  directory.  The  "symlinkO,"  "readlinkO,"  and 
"IstatO"  are  supported  by  the  SVID.  They  have  been  proposed  for  the  POSIX.la  revision. 

POSIX.  la  lacks  all  interfaces  for  mounting  file  systems  and  getting  file  system  information  about 
a  mounted  file  system  (e.g.,  "mountO,"  "statfsO,"  "statvfsO,"  "fstatfsO,"  "vstatvfsO,"  and 
"ustatO"),  and  does  not  plan  to  standardize  such  capabilities  in  the  future.  These  capabilities  are 
included  in  the  Remote  File  Access  base  service  area. 


POSIX.  1  lacks  the  following  capabilities  supported  by  the  SVID,  but  are  not  proposed  for  the 
POSIX.  la  revision.  Of  these,  "poll()“  may  be  proposed  for  the  POSIX.  1  a  revision,  and  "fsyncO" 
was  moved  to  the  POSIX. lb  real  time  standard  under  a  new  and  separate  option 
(_POSIX_FSYNC, ...): 


"ftw" 

"mknodO" 

"mktempO" 

>110" 

"syncO" 


Traverse  a  file  tree 

Make  a  special  file  (for  a  device) 
Make  a  unique  file  name 
Test  or  wait  for  file  events 
Synchronize  a  file's  state 


POSIX.  1  lacks  the  following  capabilities  to  manipulate  a  binary  search  tree:  "tsearchO,"  "tfindO," 
"tdeleteO,"  and  "twalk()."  These  capabilities  are  supported  by  X/Open,  and  the  SVID,  but  are  not 
proposed  for  the  POSIX.  la  revision. 


3.8.I.2.4  Portability  caveats.  Too  many  "standard"  file  systems  exist  This  significantly  reduces 
the  chances  of  portability.  POSIX  does  not  define  the  directory  tree  organization  or  the  files 
located  in  particular  directories.  Therefore,  applications  written  to  different  vendors'  operating 
systems  compliant  with  POSIX  may  be  nonportable.  Directory  and  file  organizations  are 
generally  similar  in  most  Unix-like  implementations.  However,  System  V.4's  directory  and  file 
organization  differs  from  the  one  in  System  V.3  and  Berkeley  Unix  and  OSF/1  (which  is  based  on 
Berkeley  Unix).  The  difference  in  the  file  and  directory  organization  is  one  of  the  major  causes  of 
nonportability  across  System  V.4  and  Berkeley  Unix. 
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3.8.  U.5  Related  standards.  The  following  standards  are  related  to  file  management  or  file 
management  standards: 

a.  IEEE  1003.2: 1992:  POSIX  -  Shell  and  Utility  Application  Interface. 

b.  IEEE  R1003.5:  1992  Ada  Language  Binding  (under  revision). 

c.  IEEE  P1003.  le:  Security  Interface  Standards  for  POSIX. 

d.  IEEE  P1387.1:  POSIX  System  Administration  -  Part  l:Overview. 

e.  IEEE  1387.2:1995:  POSIX  System  Administration  -  part  2:Software. 

f.  IEEE  P1387.3:  POSIX  System  Administration  -  Part  3:User  and  Group 
Administration. 

g.  IEEE  P1003.1g:  Protocol  Independent  Interfaces. 

h.  IEEE  1224.2-1993:  Directory  Services  Application  Program  Interface  (API). 

i.  IEEE  P1003.1f:  Network  Services  for  Portable  Application  (former  1003.8). 

j.  X/Open  Common  Desktop  Environment  (XCDE)  -  Services  and  Applications. 

3.8. 1.2.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:1995,  and  IEEE  1003.1i:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should  also  be  consulted.  It 
adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996  version.  It  specifies  group  ID 
settings.  IEEE  1003.1b  added  to  file  management  utilities  (truncate  and  synchronize)  found  in  the 
1990  version  of  9945-1.  The  SUS  adds  capabilities  for  directories  and  links. 

Directory  and  file  organizations  are  generally  similar  across  most  Unix  implementations  (e.g., 
System  V.3).  However,  System  V.4's  directory  and  file  organization  differs  from  the  one  in 
System  V.3  and  Berkeley  Unix.  Therefore,  standardization  probably  will  be  based  on  a  particular 
Unix-based  variant's  file  system  organization  (e.g.,  X/Open  XPG4,  SVID)  in  addition  to  POSIX. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensi  ins  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.1.3  Input/Output  control.  (This  BSA  appears  in  both  part  8  and  part  9.)  Input/Output  (I/O) 
control  standards  include  services  such  as  device  initialization,  device  attachment,  asynchronous 
operation,  error  notification,  raw  I/O,  and  other  services  needed  to  implement  logical  device 
drivers  in  a  system. 

Input/output  control  enables  control  of  different  media  devices  over  the  network  through 
software.  The  media  devices  include  video,  '.ssette  recorders,  laser  disc  players,  video  cameras, 
CD  players,  and  so  on.  Control  capability,  -.ay  be  available  on  the  workstation  through  a 
graphical  user  interface  (GUI).  They  are  similar  to  the  controls  on  the  device,  such  as  play, 
record,  reverse,  eject,  and  fast  forward.  Input/output  control  is  important  because  it  enables  the 
operator  to  control  video  and  audio  remotely  without  requiring  physical  access. 

3.8.1.3.1  Standards.  Table  3.8-3  presents  standards  for  input/output  control. 


TABLE  3.8-3  Input/Output  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status  1 
DoD 

(Lifecycle) 

IPC 

1SOAEC 

Portable  Operating  System  Interface  (POSIX)  Put  1 : 
System  API  (Replaces  ISO  9945-1:1990  and  incorporates 
IEEE  1003.1b,  1003.1c.  and  1003.1i) 

9945-1:1996 

Mandated 

(Approved) 

CPC 

X/Opeti 

Sngle  UNIX  Specification,  System  Interface  Definitions, 
Version  2,  Issue  5 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interfaces  and  Headers, 
Version  2,  Issue  5 

C606  (2/97) 

Hm erg  jig 
(Approved) 

GPC 

NIST 

ESlilligiB 

PIPS  PUB  151- 

2:1993 

Informational 

(Approved) 

NPC 

IEEE 

Portable  Operating  System  Interface  (POSIX)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Inform  atioi»! 
(Approved) 

NPC 

IEEE 

POSIX  Part  1:  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  1C  L  uiguage] 

1003. 1  i:  1995 

Informational 

(Approved) 

NPC 
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3.8. 1.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 
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a.  Berkeley  4.2/4.3  Unix. 

b.  OSF:  OSF/1  (product  implementation). 

3X1JJ  Standards  deficiencies.  POSIX.  1  provides  basic  input/output  primitives,  but  lacks  the 
generalized  services  needed  to  implement  device  drivers  for  many  types  of  devices.  POSIX.  lb 
provides  support  for  asynchronous  and  synchronized  I/O,  but  also  lacks  generalized  services 
needed  to  implement  device  drivers  for  many  types  of  devices. 

3.8.1.3.4  Portability  caveats.  The  "ioctl"  function,  which  is  associated  with  the  control  of  an 
asynchronous  device  (including  terminal  characteristics)  has  been  identified  repeatedly  as  a  source 
of  portability  problems.  It  is  an  old  system  call,  and  during  the  many  years  it  has  been  in  Unix, 
several  variants  have  evolved.  The  differences  appear  at  low  levels.  However,  it  is  not  always 
easy  to  spot  these  differences,  because  each  "ioctl”  is  defined  loosely  and  makes  its  own 
assumptions.  As  networking  becomes  more  common,  the  device  drivers  executing  some  code 
may  be  located  across  a  network,  remote  from  the  source  of  the  system  call.  The  many  variants 
and  interpretations  of  "iocd,"  complicate  networking  because  the  same  "ioctl"  system  call  possibly 
cannot  be  used  across  a  network  to  control  a  remote  peripheral.  For  example,  the  SVID  version 
of  "ioctl"  looks  like  a  completely  different  call.  Because  of  the  difficulty  in  reaching  agreement  on 
a  standardized  version  of  the  "ioctl,"  the  POSIX  standards  groups  eliminated  "ioctl”  from  the 
standard  early.  Because  the  POSIX.  lb  real  time  group  believes  that  most  devices  communicate 
using  "ioctl,"  there  was  a  move  to  reinstate  and  standardize  "ioctl"  in  the  P1003.1b  standard.  The 
final  result,  however,  was  the  incorporation  of  specfic  "tc"  (terminal  control)  functions  to  replace 
each  "ioctl"  function. 

The  use  of  "ioctl"  calls  to  set  certain  terminal  modes  causes  problems  because  a  single,  standard 
terminal  interface  or  portable  mechanism  to  set  the  modes  of  an  async!,ronous  terminal  does  not 
exist.  Such  a  standard  has  not  been  defined,  because  it  would  require  the  "raw"  (unprocessed) 
and  "cooked"  (processed)  modes  to  be  defined.  Defining  these  would  create  other  problems. 
However,  not  defining  them  could  cause  application  codes  to  be  written  in  a  nonportable  way. 

The  SVID  and  XPG  support  the  "ioctl"  call  as  part  of  their  device  service  interfaces.  In  practice, 
this  support  is  different  on  every  different  implementation  of  these  specifications.  The  "ioctl" 
function,  while  deprecated  for  asynchronous  terminal  control  in  favor  of  the  POSIX.  1  "tc" 
functions,  is  still  required  to  control  other,  less  common  device  types.  Unfortunately  there  is  no 
standard  for  programmatic  control  of  video  cameras,  etc.,  even  though  every  system  which 
supports  such  a  device  will  provide  the  basic  control  functionality  needed  in  some  way. 

3.8.1.3.5  Related  standards.  The  following  standards  are  related  to  input/output  control  or 
input/output  control  standards: 

a.  ISO  10164-7:  Security  Management. 

b.  IEEE  P 1 003. le:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  1003.2d:1994:  POSIX  Batch  Environment  Amendments. 
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d.  IEEE  P 1 20 1.1:  Uniform  API-GUI. 

e.  NIST  FIPS  179-1: 1995:  GNMP  (Government  Network  Management  Protocol): 
Authentication. 

f.  MIT  Consortium:  X  Window  System. 

3.8.1.3.6  Recommendations.  The  mandated  standards  arc  recommended  for  input/output 
control.  The  operating  system  standards  mandated  by  the  JTA  Version  1 .0: 1996  (ISO/IEC  9945- 
1:1990,  IEEE  1003.1b:  1993,  IEEE  1003.1c:  1995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in 
the  new  ISO/IEC  9945-1:1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should 
also  be  consulted.  It  adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996  version.  It 
specifies  read/write  functionality.  The  "tc-functions”  were  introduced  into  POSIX.l  to  solve 
portability  issues  arising  from  "ioctl"  calls.  X/Open  SUS  covers  all  the  core  POS1X  functions. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard:  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  nireads  extensions  and  dynamic  linking. 
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3.8.1.4  Interprocess  communication.  Interprocess  communication  (IPC)  facilities  enable 
different  processes  to  exchange  information,  either  within  a  single  computer,  or  across  a  network. 
Some  communications  methods  are  designed  strictly  for  use  within  a  single  computer  but  others, 
while  providing  local  communications,  were  designed  for  networked  operations.  The  following 
interprocess  mechanisms  have  been  standardized: 

a.  Message  Queues.  Message  queues  provide  a  fast  local  IPC  mechanism  well  suited 
to  real  time  applications. 

b.  FIFOS.  FIFOS,  also  known  as  "named  pipes",  provide  the  same  functionality  as 
traditional  Unix  pipes,  but  unlike  traditional  pipes,  the  readers  and  writers  of  a 
FIFO  do  not  need  to  have  an  "ancestor  process"  in  common  to  prepare  the  pipe  for 
use. 

c.  Sockets.  Berkeley  BSD  Unix  4.2  introduced  the  concept  of  the  socket  as  a 
protocol-independent  method  of  accessing  network  functionality.  The  socket  API 
provides  access  to  both  local  and  remote  processes  over  a  variety  of  network 
protocols  including  TCP/IP  and  the  OSI  protocol  family. 

d.  XTI.  XTI  is  X/Open's  specification  of  the  System  V  TLI  API,  which  also 
provides  a  protocol  independent  method  for  accessing  network  functionality. 

3.8.1.4.1  Standards.  Table  3.8-4  presents  standards  for  interprocess  communication. 


TABLE  3,8-4  Interprocess  communication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISOAEC 

Portable  Operating  System  Interface  (POSIX)  Part  I : 
System  API  (Replaces  ISO  9945- 1:1990  and  incorporates 
IEEE  1003. lb,  1003.1c,  and  1003.1i) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface. 
Volume  1  Microsoft  Win32  Programmers’  Reference 
Manual,  1993,  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  Networking  Services,  Version 

2,  Issue  5 

C523  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface  Definitions, 
Version  2,  Issue  5 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interfaces  and  Headers, 
Version  2.  Issue  5 

(-606  (2/97) 

Emerging 

(Approved) 

I  NPC 

IEEE 

Portable  Operating  System  Interface  (POSIX)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

I :  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

1003. li:  1995 

Informational 

(Approved) 

|  GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  -  System 
Application  Program  Interface/ C  Language  (adopts 
ISOflHC  9945- 1:1990} 

FIPS  PUB  151- 
2:1993 

Informational 

(Approved) 
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Standard  Sponsor 
Type 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 
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3.8.1.4.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.2/4.3  Unix. 

b.  OSF:  OSF/1  (product  implementation). 

c.  SAE  ARD  50067  Draft:  Avionics  Operating  System  API  Requirements. 

3.8.1.4.3  Standards  deficiencies.  The  POSIX.lb  message-passing  services  are  minimal  and  are 
designed  with  emphasis  on  performance  rather  than  robustness  to  make  the  best  match  of 
functions  and  interfaces  of  real  time  kernels  used  for  embedded  systems.  POSIX.lb  only  supports 
sending  messages  between  processes  on  a  single  machine  (no  network  capability  is  specified). 
POSIX.lb  does  not  support  the  ability  to  wait  on  multiple  message  queues  simultaneously  and 
does  not  provide  a  facility  to  broadcast  a  single  message  to  multiple  queues. 

3.8.1.4.4  Portability  caveats.  The  POSIX.lb  message-passing  interface  differs  from  and  is 
incompatible  with  the  message- passing  interfaces  in  XPG4,  SVID,  and  Berkeley  Unix.  However, 
XPG3,  XPG4,  SVID,  and  Berkeley  Unix  support  the  same  message  passing  interfaces. 

POSIX.lb  message  passing  interfaces  designate  separate  commands  for  each  function,  rather  than 
following  the  SVID  technique  of  providing  a  single  command  with  multiple  variables  for  many 
functions. 

The  POSIX. lb  message-passing  interface  includes  asynchronous  notification  to  apprise  a  task  of 
the  availability  of  a  message  on  the  queue.  The  receiving  task  is  notified  of  the  time  at  which  a 
message  was  sent,  the  sender  of  the  message,  and  the  use  of  pathnames  for  identifying  message 
queues.  Neither  System  V  nor  Berkeley  Unix  providers  such  an  asynchronous  notification. 

POSIX.lb  message  prioritization  allows  the  application  to  determine  the  order  in  which  messages 
are  received.  Prioritization  of  messages  is  a  key  facility  provided  by  most  real  time  kernels,  is 


April  7,  1997 


3.8-12 


Version  3.1 


Information  Technology  Standards  Guidance 


Operating  System  Services 


used  heavily  by  the  applications,  and  helps  to  avoid  priority  inversions  in  the  message  system. 
Neither  System  V  Streams  nor  Berkeley  Unix  sockets  supports  classification  of  message  and  out- 
of-order  selective  receipt  according  to  the  classification.  This  POSDC.lb  capability  allows 
applications  to  be  designed  to  eliminate  a  significant  problem  with  Ada  rendezvous  in  which  Ada 
queues  tasks  in  strict  FIFO  order,  ignoring  priorities.  However,  it  also  increases  the 
incompatibilities  between  POSIX.  lb  and  the  SVID. 

3.8. 1.4.5  Related  standards.  The  following  standard  is  related  to  interprocess  communication: 
a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

3.8.1.4.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003. 1  b:  1993, 
IEEE  1003.1c:  1995,  and  IEEE  1003.11:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 

1 : 1 996.  If  real-time  IPC  is  required  on  a  single  computer,  then  POSIX.  1  b  message  queues 
(incorporated  into  ISO/IEC  9945-1:1996)  are  recommended.  Unfortunately,  there  are  as  yet,  no 
internationally  approved  standards  for  real-time  IPC  between  computers  on  a  network.  However, 
both  the  IEEE  P1003.1g  and  the  IEEE  P1003.21  draft  standards  provide  APIs  for  process-to- 
process  communication  over  a  network.  If  a  broad  range  of  IPC  mechanisms  are  required,  then 
X/Open  SUS  should  be  considered,  since  it  provides  the  full  range  of  functions. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-speciftc  Threads  extensions  and  dynamic  linking. 
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3.8. 1.5  Environment  and  internationalization  services.  Environment  and  internationalization 
(I18N)  services  provide  an  application  with  a  variety  of  attributes  and  variables  to  set  and  retrieve 
attributes  of  the  operating  system  environment  in  which  the  application  is  executing.  Some  of  the 
environment  attributes  which  are  usually  available  are  user  ID,  group  ID,  process  ID,  terminal  ID, 
network  node  identification,  stack  size,  and  current  time  and  date.  The  1 1 8N  attributes  that  are 
available  are  timezone,  language  to  be  used  for  messages,  currency  symbol,  and  date  format 


3.8.1.5.1  Standards.  Table  3.8-5  presents  standards  for  environment  and  internationalization 
services. 

TABLE  3.8-5  Environment  and  internationalization  services  standards 


Standard 

Reference 


Mandated 

(Approved) 


Mandated 

(Approved) 


Mandated 

(Approved) 


Mandated 

(Approved) 


Emerging 

(Approved) 


Emerging 

(Approved) 


Emerging 

(Approved) 


Informational 

(Approved) 


Standard 

Type 

Sponsor 

Standard 

IPC 

ISO/IEC 

Portable  Operating  Syitem  Interface  (POStX)  Part  1 : 
Syitem  API  (Replace!  ISO  9945- 1:1990  and  incorporates 
EFE  1003.1b.  1003.1c.  and  1003.1i) 

IPC 

ISO/tFC 

Information  Technology  -  Portable  Operating  Syitem 
Interface  (POSEX)  -  Part  2:  Shell  and  Utilities  (as  profiled 
by  FIPS  PUB  189:1994) 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDE  Services 
and  Applications 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDE  Definitions 
and  Infrastructure 

CPC 

X/Open 

Single  UNDC  Specification,  Commands  and  Utilities,  Issue 
5,  Version  2 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface  Definitions, 
Version  2.  Issue  5 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interfaces  and  Headers, 
Version  2,  Issue  5 

GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  -  System 
Application  Program  Interface/  C  Language  (adopts 
ISO/IEC  9945-1:1990) 

GPC 

NIST 

C  (Adopts  ANSI/1SO/1EC  9899:1992) 

GPC 

NIST 

Representation  of  Calendar  Date  and  Ordinal  Dale  for 
Information  Interchange  (adopts  ANSI  X3.30- 
1985/RI99I) 

C323  (4/95) 


C324  (4/95) 


C604  (2/97) 


C605  (2/97) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifetyde) 

1 

3.8. U. 2  Alternative  specifications.  The  following  specification  is  also  available: 
a.  Berkeley  4.2/4.3  Unix. 

3.8. 1.5 3  Standards  deficiencies.  ANSI  C  defines  the  base  functionality  for  program 
internationalization,  but  it  is  lacking  in  certain  areas.  X/Open  Single  Unix  Specification  (SUS) 
provides  a  full  set  of  internationalization  APIs,  but  its  support  for  multibyte  character  sets  (such 
as  those  used  by  Asian  languages)  is  based  on  an  old  draft  of  the  MSE  standard  from  ISO. 

ISO/IEC  9945-1:1996  POSIX.l  does  not  support  the  function  "cuseridO"  to  get  the  control 
terminal  login-user  name,  even  though  this  function  was  specified  in  the  IEEE  POS1X.  1 : 1 988 
standard. 

POSIX.2  lacks  several  environment  variables  present  in  the  SVID,  such  as  "SEV_LEVEL"  (to  set 
the  severity  level  for  error  messages),  "MSGVERB"  (message  format  selection  control),  and 
"NETPATH"  (network  identifiers). 

POSIX.l  does  not  support  the  "putenvO"  function  to  add  or  change  an  environment  variable  or 
the  "clearenvO"  variable  to  clear  the  process  environment,  because  these  functions  were 
considered  to  be  more  oriented  toward  system  administration  than  ordinary  applications. 

Objectors  have  since  identified  application  uses,  and  the  "putenvO"  and  "clearenvO"  functions 
have  been  proposed  for  the  POSIX.  la  revision. 

3.8.1. 5.4  Portability  caveats.  A  number  of  locale-specific  environment  variables  associated  with 
POSIX  actually  are  set  in  the  American  National  Standards  Institute  (ANSI)  C  <locale.h> 
headers.  As  a  result,  non-POSIX  operating  systems  can  provide  a  certain  degree  of  compatibility 
with  operating  systems  based  on  POSIX.  For  the  same  reasons,  systems  compliant  with  POSIX 
and  running  Ada,  Fortran,  and  other  non-C  programs  may  exhibit  areas  of  incompatibility.  The 
environment  variables  and  functions  related  to  internationalization  face  potential  application 
portability  problems. 

The  function  "cuseridO"  (common  terminal  login  user  name)  is  specified  by  X/Open  (to  be 
withdrawn),  and  the  SVID,  but  not  POSIX. 

The  POSIX  "getgrpO"  function  to  obtain  the  process  group  ID  for  a  specified  process  is  based  on 
the  System  V  "getpgrpO"  function,  rather  than  the  more  complex  Berkeley  4.3  Unix  "getpgrpO" 
function  and  is  incompatible  with  the  Berkeley  Unix  function. 

The  "putenvO"  function  is  specified  by  X/Open  and  the  SVID,  but  not  by  POSIX. 
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The  "clearenvO"  function  is  specified  only  by  OSF/1. 

Because  the  multibyte  character  support  mandated  by  X/Open  is  required  to  conform  to  an  older 
draft  of  the  ISO  MSE,  there  will  be  portability  problems  when  moving  internationalized  code 
between  systems  which  conform  to  X/Open  SUS  and  systems  which  have  been  tracking  the 
emerging  standards  in  this  area  mote  closely.  Once  the  draft  MSE  standard  has  been  approved, 
X/Open  will  be  aligning  SUS  with  the  standard. 

3.8.1.5.5  Related  standards.  The  following  standards  are  related  to  environment  services  or 
environment  services  standards: 

a.  X/Open  T906:3/95:  X/Open  Portability  Guide  (XPG4). 

3.8.1.5.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:  1995,  and  IEEE  1003.1i:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should  also  be  consulted.  It 
adopted  ISO  9945- 1 : 1 990  and  is  still  applicable  to  the  1 996  version.  It  specifies  the  number  of 
group  IDs.  SUS  adds  I18N  APIs.  FIPS  160  defines  program  II 8N.  Use  the  function 
"getpwuid(geteuid())"  to  get  the  information  previously  supplied  by  the  no  longer  supported 
POSIX.l  function  "cusr,rid()." 

Systems  requiring  the  "MSG VERB"  environment  variable  or  the  Berkeley-style  "getpgrp"  call 
should  specify  conformance  to  X/Open's  Single  Unix  Specification  (Spec  1 170),  which  includes 
POSIX.l  conforming  APIs,  as  well  as  the  traditional  interfaces  and  functions  discussed  above. 
Regardless,  non-POSIX  APIs  should  be  avoided,  if  there  is  a  POSIX  interface  which  provides 
equivalent  functionality,  in  order  to  increase  the  portability  of  the  application  to  future  platforms. 
Systems  which  will  be  made  available  to  NATO  partners  and  thus  require  the  ability  to  support 
multiple  languages  should  mandate  X/Open  SUS  conformance. 

In  a  GUI  environment,  XCDE  provides  information  about  screen  size,  resolution,  number  of 
colors  available,  and  other  programs  which  are  active. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3  A  1.6  Login  services.  To  login  is  to  gain  access  or  sign  in  to  a  computer  system.  If  restricted, 
it  requires  a  user  to  identify  himself  by  entering  an  ID  number  and/or  password. 

3.8.1.6.1  Standards.  Table  3.8-6  presents  standards  for  login  services. 


TABLE  3.8-6  Login  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

XfO/m 

■SSM 

3.8.1.6.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.2/4.3  Unix. 

b.  OSF:  OSF/1. 

3.8.1.6.3  Standards  deficiencies.  The  current  operating  system  standards  do  not  specify  login. 
An  operating  system  must  provide  a  way  to  login,  so  implementations  provide  this  service  in 
nonstandard  ways. 

3.8.1.6.4  Portability  caveats.  Because  login  services  are  used  almost  exclusively  by  users,  rather 
than  applications,  the  only  difficulty  caused  by  the  lack  of  login  service  standards  is  one  of 
drivability.  Login  was  not  included  in  X/Open's  Single  Unix  Specification  because  login  utility  is 
terminal  oriented,  not  used  by  application  programs. 

3.8.1.65  Related  standards.  The  following  standards  are  related  to  login  services  or  login 
service  standards: 

a,  IEEE  P 1 20 1.1:  Uniform  API-Graphical  User  Interfaces. 

3.8.1.6.6  Recommendations.  There  are  no  recommended  standards. 
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3.8.1.7  Storage  device  management.  (This  BSA  appears  both  in  part  8  and  part  9.)  Storage 
device  management  is  familiar  to  most  people  as  "Logical  Volume  Management."  With  logical 
volume  management,  a  logical  volume  manager  provides  disk  partition  flexibility  by  allowing  the 
disk  partitions  to  grow  automatically  as  the  system  runs,  and  by  allowing  files  to  span  physical 
volumes.  This  allows  a  given  file  to  be  larger  than  any  one  disk.  This  flexibility  is  possible 
because  the  logical  volume  manager  manages  the  disk  space  by  creating  what  it  calls  "logical 
volumes."  The  logical  volume  manager  determines  the  correspondences  between  the  logical 
volumes  and  the  actual  physical  volumes.  A  logical  drive  is  an  allocated  part  of  a  physical  drive 
designated  and  managed  as  an  independent  unit  Hierarchical  storage  management  and  archiving 
addresses  the  ability  to  handle  different  levels  of  storage  transparently,  such  as  disks,  tapes,  and 
juke  boxes. 

3.8.1.7.1  Standards.  Table  3.8-7  presents  standards  for  storage  device  management. 


TABLE  3.8-7  Storage  device  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Distributed 
File  Service  (DFS) 

DCE  1.1  DFS:  1994 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmers'  Reference 
Manual,  1993,  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

CPC 

OSF 

DCE  1.1  NFS:  1994 

Informational 

(Approved) 

CPC 

OSF 

QSF/l  Operating  System 

QSF/l  O.S. 

Informational 

(Approved) 

CK 
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3.8.1.7.2  Alternative  specifications.  Future  releases  of  SVR4  will  support  the  Logical  Volume 
Manager,  but  no  other  alternative  specifications  are  available. 

3.8.1.7.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.1.7.4  Portability  caveats.  Portability  caveats  are  unknown  at  this  time. 

3.8. 1.7.5  Related  standards.  No  standards  are  related  to  storage  device  management. 

3.8. 1.7.6  Recommendations.  Open  Software  Foundation's  Distributed  File  Service  is 
recommended.  Logical  volume  managers  are  extremely  valuable,  as  many  system  managers  know 
who  have  had  to  back  up  a  system,  take  it  down,  repartition  it  to  accommodate  the  growth  of 
applications  and  data  in  certain  partitions,  and  restore  the  system,  only  to  do  the  same  thing 
months  later.  The  logical  volume  manager  eliminates  this  problem  by  allowing  partitions  to  grow 
dynamically. 
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3J.U  System  operator  services.  System  operator  services  are  used  by  a  system  administrator 
or  network  manager  to  monitor  a  system  or  network,  usually  on  a  console  or  another  computer. 

3.8.1.8.1  Standards.  Table  3.8-8  presents  standards  for  system  operator  services. 


TABLE  3.8-8  System  operator  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

tPC 

ISO/EC 

9945-1:1996 

Mandated 

(Approved) 

NPC 

IEEE 

Portable  Operating  Syrian  Interfax  (POSIX)  -  Pat  1 : 
Syrian  Application  Program  Interface  (API)  Amendmoit 

I:  Realtime  Extent  ion  (C  language) 

1003. lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  Syrian  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigeoda  to  Real  Time 
Extension  [C  Language] 

1003-  li:  1995 

Informational 

(Approved) 

GPC 

NIST 

KSHilSl 

mm 

Informational 

(Approved) 

'  1 

MUM 

I  | 

MB 
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(TMU 

W3i 
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3.8. 1.8.2  Alternative  specifications.  The  following  specification  is  also  available: 

a.  Berkeley  4.2/4.3  Unix. 

3.8.1.8.3  Standards  deficiencies.  POSIX  lacks  services  allowing  the  system  operator  to  control 
the  system  services  or  reconfigure  system  software  so  that  the  platform  can  perform  properly. 
POSIX  has  only  minimal  services  and  interface  to  access  configuration  information  or  system 
status. 

3.8.1.8.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.8.1.8.5  Related  standards.  The  following  standards  are  related  to  system  operator  services  or 
system  operator  service  standards: 

a.  IEEE  1003.2:1992:  POSIX  -  Shell  and  Utility  Application  Interface. 

b.  IEEE  P1003.1e:  Security  Extension  to  POSIX. 

c.  IEEE  P1387.1:  POSIX  System  Administration  -  Part  1:  Overview. 

d.  IEEE  1 387.2: 1995:  POSIX  System  Administration  -  Part  2:Software. 
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e.  IEEE  P1387.3:  POSIX  System  Admini  radon  -  Part  3:  User  and  Group 
Administration. 

f.  IEEE  P1003.1g:  Protocol  Independent  Interfaces. 

g.  IEEE  1224.2:1993:  Directory  Services  API  Language  Independent. 

h.  IEEE  P 1 20 1.1:  Uniform  API-Graphical  User  Interfaces. 

L  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation:  API  (X.400). 

j.  IEEE P1238.1:  OSI  API- FTAM. 

k.  IEEE  P 1 35 1 :  OSI  API  -  ACSE. 

L  NIST  FIPS  179-1:1995  GNMP. 

3.8.1.8.6  Recommendations.  The  mandated  standards  are  recommended.  ISO  9945-1 : 1996 
incorporates  IEEE  1003.1b  which  standardizes  scheduling  functions  not  in  the  original  POSIX.l. 
FIPS  151-2  specifies  job  control  functions.  POSIX  provides  only  minimal  operator  services. 
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3 A  1.9  Process  checkpoint  and  restart.  (This  BSA  appears  both  in  part  8  and  part  9.) 
Checkpoint  and  restart  is  a  method  of  recovering  from  a  system  failure.  A  checkpoint  is  a  copy  of 
the  computer's  memory  saved  periodically  on  disk  along  with  the  current  register  settings  (e.g., 
the  last  instruction  executed).  In  the  event  of  any  failure,  the  last  checkpoint  serves  as  a  recovery 
point  When  the  problem  has  been  fixed,  the  restart  program  copies  the  last  checkpoint  into 
memory,  resets  all  the  hardware  registers,  and  starts  the  computer  from  that  point.  Any 
transactions  in  memory  after  the  last  checkpoint  was  taken  until  the  failure  occurred  will  be  lost 
Checkpoint  restart  is  helpful  in  any  system  running  long  jobs  and  requiring  more  time  than  can  be 
expected  between  system  down-times,  and  in  any  job  that  would  be  inconvenient  to  start  over  in 
the  event  of  a  system  failure. 

3.8.1.9.1  Standards.  Table  3.8-9  presents  standards  for  process  checkpoint  and  restart. 


TABLE  3.8-9  Process  checkpoint  and  restart  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

tai 

3.8.1.9.2  Alternative  specifications.  The  only  other  specifications  available  are  proprietary. 

3.8. 1.9.3  Standards  deficiencies.  P1003.1a  does  not  specify  how  files  and  directories  are 
identified  in  the  checkpoint  file. 

3.8.1.9.4  Portability  caveats.  One  checkpoint  restart  implementation  provides  a  value  of 
"RESTART_FORCE"  to  restart  a  checkpoint  file  or  directory,  whether  or  not  it  could  be 
restarted  rationally.  This  behavior  cannot  be  used  in  a  portable  way,  since  no  predictable  meaning 
exists  for  restarting  a  process  that  was  in  a  condition  that  could  not  be  checkpointed. 

3.8.1.9.5  Related  standards.  ISO  IS  9804/9805:  CCR  is  related  to  process  checkpoint  and 
restart. 

3.8.1.9.6  Recommendations.  Too  many  unresolved  issues  are  in  the  checkpoint  restart 
specification  in  the  P1003.1m  draft  standard  to  specify  the  emerging  checkpoint  restart 
specification.  Issues  range  from  the  error  codes  to  how  much  of  the  process  state  to  specify 
explicitly. 

Checkpoint/restart,  originally  in  P1003.  la  system  services  as  a  separate  API  is  now  a  separate 
IEEE  project  work  item  under  P1003.1m.  This  work  was  started  by  the  Super  Computer  and 
Batch  processing  systems  working  groups  in  conjunction  with  the  PI0O3.1a  working  groups  to 
provide  mechanisms  to  suspend  a  long  executing  job  and/or  provide  checkpoints  along  the  way  so 
it  could  be  restarted  if  something  happened  during  execution. 
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3.8.1.10  System  resource  limits.  (This  BSA  appears  both  in  part  8  and  part  9.)  Resource  limits 
functionality  allows  system  administrators  to  control  the  amount  of  system  resources  available  to 
users. 

3.8.1.10.1  Standards.  Table  3.8-10  presents  standards  for  system  resource  limits. 


TABLE  3.8-10  System  resource  limits  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

XJOpen 

Single  UNIX  Specification,  Syrtern  Interfaced  and  Headen, 
Vcn ion  2,  luue  5 

C606  (2/97) 

Adopted 

(Approved) 

NPC 

IFFE 

1003.10:1995 

Informational 

(Approved) 

m  - 
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3.8.1.10.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.3  Unix. 

b.  Cray  Research,  Inc.:  "limits"  interfaces. 

c.  OSF:  OSF/1  Operating  System:  "getrlimit/setrlimit" 

3.8.1.103  Standards  deficiencies.  The  Berkeley  Unix  and  System  V  "setrlimit"  and  "ulimit" 
interfaces  have  the  limitation  that  users  may  act  only  to  make  their  limits  more  restrictive. 

3.8.1.10.4  Portability  caveats.  The  actual  numeric  limit  values  for  different  resource  limits  are 
not  portable  across  various  platforms.  Applications  need  to  provide  some  sort  of  configuration 
parameters  to  specify  the  actual  numeric  values  for  each  site. 

3.8.1.10.5  Related  standards.  The  following  standards  are  related  to  resource  limits  or  resource 
limit  standards: 


a.  ISO/IEC  9945-1:1996:  POSIX.  1  System  Application  Programming  Interfaces. 

b.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  PI 387.1:  POSIX  System  Administration  -  Part  1:  Overview. 

d.  IEEE  1003.2d:  1 994:  POSIX  Batch  Environment  Amendments. 

3.8.1.10.6  Recommendations.  X/Open  Single  Unix  Specification  (SUS)  provides 
"setrlimit/getrlimit"  functionality. 
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Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.1.11  Kernel  language  bindings.  These  standards  provide  programming  language  interfaces 
to  kernel  services. 

3.8.1.11.1  Standards.  Table  3.8-1 1  presents  standards  for  kernel  language  bindings. 

TABLE  3.8-11  Kernel  language  bindings  standards 


Standard 

Reference 


Standard 

Type 

Sponsor 

IPC 

ISO/TEC 

CPC 

X/Open 

CPC 

X/Open 

NPC 

IPFP 

NPC 

IFEF. 

NPC 

IEEE 

NPC 

fPEF. 

NPC 

IEEE 

NPC 

IEEE 

GPC 

NIST 

Portable  Operating  Syrtan  Interface  (POStX)  Part  1 : 
System  API  (Replaces  ISO  9945-1 : 1990  and  incorporates 
IEEE  1003.1b.  1003.1c,  and  1003.11) 


Single  UNIX  Specification,  Networking  Services,  Version 
2.  Issue  5 


Single  UNIX  Specification,  System  Interfaces  and  Headers, 
Version  2.  Issue  5 


POSIX  Part  1 :  System  Application  Program  interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  1C  Lan 


Mandated 

(Approved) 


POSIX  FORTRAN  77  Language  Interfaces  -  Part  1: 
Binding  for  System  API 


Test  Methods  for  Measuring  Conformance  to  POSIX  • 
System  Interfaces 


C523  (2/97) 

Emerging 

(Approved) 

C606  (2/97) 

Emerging 

(Approved) 

1003.  lb:  1993 

Informational 

(Approved) 

1003.1i:1995 

Informational 

(Approved) 

1003.5:1992 

InfomuUional 

(Approved) 

1003.5b:  1996 
(former  1003.20) 

Informational 

(Approved) 

1003.9:1992 

Informational 

(Approved) 

2003.1:1992 

Informational 

(Approved) 

FIPS  PUB  151- 
2:1993 

Informational 

(Approved) 
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3.8.1.11.2  Alternative  specifications.  No  applicable  consortia  or  industry  specifications  for 
kemal  bindings  to  C  or  Ada  exist  because  ANSI  C  and  ISO  Ada  bindings  are  provided  by  the 
standard.  However,  XPG4,  SVTD,  and  OSF/1  include  a  C  language  binding. 

3.8.1.11.3  Standards  deficiencies.  No  standard,  consortia,  or  de  facto  specifications  exist  or  are 
in  progress  for  POSIX.l,  Unix,  or  OSF/1  bindings  to  Cobol,  C++,  APL,  Common  Lisp,  Modula- 
2,  PL/1,  or  Prolog. 

3.8.1.11.4  Portability  caveats.  The  Fortran-77  binding  uses  some  nonstandard  features,  such  as 
longer  names,  that  the  proposers  believed  will  become  available  soon  in  compilers  and  linkers. 
Also,  under  the  Fortran-77  binding,  all  system  service  calls  begin  with  the  characters  "F77."  In 
addition,  the  Fortran-77  binding  uses  procedure  calls  for  all  interactions  with  system  services, 
instead  of  using  traditional  Fortran  statements  like  "OPEN"  and  "READ"  to  accomplish  similar 
tasks.  Such  non-Fortran  standard  features  leave  open  questions  about  interactions  between  the 
redundant  ways  of  doing  things,  and  the  intermixing  of  POSIX  calls  and  ordinary  Fortran-77 
services  dealing  with  the  same  resources. 

The  C  language  bindings  have  no  known  problems. 

3.8.1.11.5  Related  standards.  The  following  standards  are  related  to  kemal  language  bindings: 

a.  ISO  1539:1991:  Fortran-90. 

b.  ISO  8652,  FIPS  1 19,  DOD  MIL-STD  1815A:1983:  Ada. 

c.  IEEE  1003.2:1992:  POSIX  -  Shell  and  Utility  Application  Interfaces. 

d.  IEEE  P1003.2a:  POSIX  -  User  Portability  Extension. 

e.  ANSI  X3.9-1978:  Fortran-77. 

f.  ANSI  9899-1990:  C  Programming  Language. 

g.  X/Open  C140:8/91:  Xlib  -  C  Language  Binding. 

3.8.1.11.6  Recommendations.  The  operating  system  standards  mandated  by  the  JTA  Version 
1.0:1996  (ISO/1EC  9945-1:1990,  IEEE  1003. lb:  1993,  IEEE  1003. lc:  1995,  and  IEEE 
1003.  li:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945-1:1996.  Federal  Information 
Processing  Standard  (FIPS)  151-2  should  also  be  consulted.  It  adopted  ISO  9945-1:1990  and  is 
still  applicable  to  the  1996  version.  ISO/IEC  9945- 1 : 1 996  and  FIPS  151-2  provide  binding 
guidance  to  POSIX.  1 .  The  operating  system  binding  requirement  for  FIPS  151-2  must  reflect  the 
programming  language  used  in  the  application.  POSIX  1003,5  and  1003.9  provide  binding 
guidance  for  other  languages.  X/Open  Single  Unix  Specification  Networking  Services  covers  the 
interfaces  in  the  IEEE  draft  P1003.1g,  Protocol  Independent  Interfaces.  The  Fortran-77  binding 
is  quite  workable,  and  undoubtedly  will  provide  the  means  for  making  POSIX  services  more 
available  to  Fortran  programs.  Some  members  of  the  POSIX.9  Group  have  characterized  the 
Fortran-77  bindings  as  a  "stopgap"  measure  while  defining  the  POSIX.l  binding  for  Fortran  90, 
an  area  in  which  work  has  begun. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX. 2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
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Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.1.12  Threads  interface.  (This  BS  A  appears  in  both  part  8  and  part  1 1.)  A  traditional  UNIX 
process  has  a  single  thread  of  control.  A  thread  of  control,  or  more  simply  a  thread,  is  a  sequence 
of  instructions  executed  in  a  program.  A  thread  has  a  program  counter  (PC)  and  a  stack  to  keep 
track  of  local  variables  and  return  addresses.  A  thread  is  one  transaction  or  message  in  a 
multithreaded  system  or  an  individual  process  within  a  single  application.  Thread  interfaces  are 
specifications  for  interfacing  with  these  processes. 

Thread  services  provide  an  underlying  service  for  multiple  concurrent  executions  within  a  single 
computer  process.  They  are  designed  to  allow  independent  operation  and  are  essential  for 
functions  such  as  multiple  process  communications  in  a  distributed  computing  environment 
Threads  provide  improved  software  responsiveness  through  increased  use  of  the  inherent 
synchronous  execution  (i.e.,  parallelism)  of  programs.  The  threads  service  in  DCE  allows  all 
DCE-enabled  applications  to  execute  multiple  actions  simultaneously.  Applications  can  accept 
information  from  users,  execute  RPCs,  and  access  databases  at  the  same  time.  The  threads 
service  is  used  by  several  DCE  services,  including  the  RPC,  Security,  Directory,  and  Time 
Services.  The  OSF  has  designed  the  threads  service  to  be  easily  accessible  by  programmers 
wishing  to  use  it  in  applications.  Services  can  be  accessed  through  the  C  programming  language, 
and  through  other  high-level  programming  languages. 

3.8.1.12.1  Standard.  Table  3.8-12  presents  standards  for  threads  interface. 


TABLE  3.8-12  Threads  interface  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

n*c 

1SO/IEC 

Portable  Operating  System  Interface  (POSDC)  Part  1: 
System  API  (Replace*  ISO  9945*1 : 1990  and  incorporates 
IEEE  1003.1b.  1003.1c.  and  1003.H) 

9945*1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Prog  rammers'  Reference 
Manual,  1993,  Microsoft  Press 

Win32  API* 

Mandated 

(Approved) 

NPC 

IttRE 

POSIX  Part  1:  System  Application  Program  Interface 
(API)  Amendment  2:  Threads  Extension  (C  language | 

I003.1c:  1995 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Threads 
(based  on  the  draft  4  venion  of  IEEE  1003.1c.) 

DCE  1.1 
Threads:  1994 

Informational 
(Approved)  J 

Hill 

taw 

a  i 

...  fegjtaaji 

fp| 

liiiiaili 

iilSBll! 

Atpott  Thwiada  Ejmwion 

AapettDwM* " 

3.8.1.12.2  Alternative  specification.  The  OSF/1  Operating  System's  Mach-Based  Multithreaded 
Kernel  is  also  available. 

3.8.1.12.3  Standard  deficiencies.  Because  the  Pthreads  interface  is  not  designed  specifically  for 
Ada,  it  can  impose  a  great  overhead  burden  on  an  Ada  run-time  system.  The  Ada  rendezvous 
feature  is  not  supported  by  Pthreads,  which  is  a  major  problem  for  real  tme  applications. 
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OSF  DCE  Threads  are  incompatible  with  Ada  Tasking.  Programmers  can  use  one  or  the  other, 
but  not  both.  Since  DCE  Threads  underlie  OSF  RPC,  Ada  progrmmers  should  be  cautious  in  the 
use  of  tasking.  (Reference:  Understanding  DCE  by  Rosenberry,  Kenney,  and  Fisher) 

3.8.1.12.4  Portability  caveats.  Ada83  and,  to  an  even  greater  extent,  Ada9x  already  contain 
many  of  the  capabilities  defined  in  the  1003.  lc  standard.  This  can  cause  many  conflicts  with  Ada. 
Vendors  may  implement  Ada  tasks  in  a  way  that  interferes  with  the  implementation  of  Pthreads. 
Also,  if  the  Ada  vendor  does  not  implement  tasks  as  pthreads,  conflicts  may  arise  between  what 
Ada  can  and  cannot  do  and  what  pthreads  can  do.  For  example,  the  Ada  rendezvous  feature  is 
not  supported  by  Pthreads.  On  the  other  hand,  Pthreads  provides  some  extended  features,  such  as 
dynamic  priorities,  that  have  not  been  standardized  by  the  Ada  language,  but  that  are  in  demand, 
especially  by  real  time  users. 

3.8.1.12.5  Related  standards.  The  following  standards  are  related  to  threads  services: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POS1X. 

b.  IEEE  P1003.21:  POSIX  -  Real  Time  Distributed  Systems  Communication. 

c.  NIST  FIPS  151-2: 1993,  Portable  Operating  System  Interface  (POSIX)-System 
Application  Program  Interface  [C  Language]  (ISO/IEC  9945- 1 : 1 990)  1 993. 

3.8.1.12.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.  lb:  1993, 
IEEE  1003.1c:1995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  The  OSF  DCE  threads  is  based  on  a  draft  version  of  IEEE  P1003.1c  Pthreads.  OSF 
intends  to  move  to  the  new  IEEE  1003.  lc  standard  in  a  future  version  of  DCE.  In  the  meantime, 
DCE  users  should  specify  DCE  threads  to  ensure  compatibility  with  currently  available  DCE 
products.  However,  they  should  also  specify  that  these  products  will  be  able  to  migrate  to  the 
new  version  of  DCE  when  OSF  adopts  the  approved  1003.1c  standard. 

To  the  extent  an  Ada  runtime  system  uses  standard  POSIX  interfaces,  it  will  be  portable  across 
operating  systems  compliant  with  POSIX.  Some  of  the  problems  caused  by  Ada  operations  not 
currently  mapped  to  Pthreads  will  be  resolved  by  the  Ada  binding  to  the  1003.1c  Pthreads 
standard. 
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3.8.1.13  Threads  extension  language  binding.  These  standards  provide  a  programming 
language  interface  to  POSIX. 

3.8.1.13.1  Standards.  Table  3.8-13  presents  standards  for  threads  extension  language  binding. 


TABLE  3.8-13  Threads  extension  language  binding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hi 

3.8.1.13 2  Alternative  specifications.  The  POSIX/Ada  Real-Time  (PART)  project  (a  project  at 
Florida  State  University,  Tallahassee,  FL,  which  is  funded  by  the  Ada  Joint  Program  Office  under 
the  Ada  Technology  Insertion  Program  through  the  U.S.  Army  Communications-Electronics 
Command  (CECOM)  and  Telos  Corporation)  has  developed  an  Ada  binding  specification  for 
P1003.  lc  (formerly  P1003.4a)  Pthreads. 

Studies  show  that  POSIX  Pthreads  conflict  with  Ada.  (The  Ada-Pthreads  conflicts,  under 
"Portability  caveats,"  are  taken  from  David  K,  Hughes'  (Comcon,  Inc.,  Moorestown,  NJ)  paper 
circulated  in  POSIX.5  (Ada  Bindings)). 

3.8.1.13 3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these 
services  are  not  part  of  any  formal  standard. 

3.8.1.13.4  Portability  caveats.  Developing  an  Ada  binding  for  the  Pthreads  Extension  to  POSIX 
will  be  more  difficult  than  developing  the  Ada  binding  for  P1003.1  and  P1003. lb  because  the 
overlap  between  the  services  provided  by  Pthreads  and  the  Ada  language  is  much  greater.  This 
can  cause  model,  style,  and  kernel-level  conflicts.  Similar  problems  arising  with  signals  and 
process  creation  in  the  P1003.5  standard  were  resolved  by  reserving  certain  operations  for  use  by 
the  Ada  run-time  system  and  providing  some  operations  to  the  application  with  warnings  that  they 
are  unsafe.  This  approach  also  can  be  used  with  Pthreads,  but  it  will  need  to  be  applied  to  the 
whole  Pthreads. 

The  following  are  some  of  the  Ada-Pthreads  conflicts,  excerpted  from  Hughes'  paper: 

a.  pthread_once.  Use  of  pthread_once  would  affect  style  adversely. 

b.  pthread_create.  Pthread_c reate  is  not  consistent  with  elaboration, activation,  or 
dynamic  allocation  of  task.  It  is  in  direct  conflict  with  Ada  at  the  application  level. 

c.  pthread_attr_setlgetstacksize.  Without  access  to  pthread_create,  these  functions 
can  have  no  effect  on  an  underlying  pthread  implementation  of  Ada  tasks  from  the 
application  level. 
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d.  pthreadjoin.  Pthread Join  is  not  like  Ada.  It  does  not  conflict  with  any  Ada 
construct  directly,  but  can  interfere  with  task  rendezvous  and  task  hierarchy.  It 
requires  a  link  with  RTS  from  the  application  level. 

e.  pthread_detach.  Pthread_detach  may  conflict  with  implementation  specific  and 
implementation-defined  pragmas. 

f.  pthread_exit  Pthread_exit  conflicts  with  scoping  rules  and  Ada  task  termination 
semantics  at  the  application  level. 

g.  pthread_mutex*_*. 

h.  pthread_cond*_*.  Pthread_cond*_*  has  an  adverse  effect  on  Ada  programming 
conventions  at  the  application  level,  with  potential  for  run-time  complexity  and 
conflict.  Interference  with  implementation-defined  pragmas  is  a  real  danger.  The 
shared  memory  semantics  are  problematic.  Its  signal  effects  by  priority  are  also 
problematic. 

i.  pthreadjtill.  Pthreadjdll  conflicts  with  abort  at  the  application  level. 

j.  pthread_cancel. 

k.  pthread_setintr. 

l.  pthread_setintrtype. 

m.  pthread_testintr.  Pthread  Jestintr  is  in  direct  conflict  with  Ada  at  all  levels. 

n.  pthread_cleanup_pushlpop.  Pthread_cleanup_pushlpop  is  tied  to  thread 

cancellation.  It  is  fundamentally  incompatible  with  Ada  style,  because  it  lacks 
pointer-to-function  in  Ada.  Visibility  at  the  application  level  is  hazardous,  as  RTS 
may  rely  on  the  content  of  the  cancellation  handler. 

3.8.1.13.5  Related  standards.  The  following  standards  are  related  to  POSIX.lc  bindings: 

a.  ISO/IEC  9945- 1 : 1 996:  POSIX  System  Application  Programming  Interfaces. 

b.  IEEE  P1003,le:  Security  Extension  to  POSIX. 

c.  IEEE  P1003.5b:  POSIX  -  Ada  Language  Interfaces  --  Part  1 :  Binding  for  Realtime 
Extensions. 

3.8.1.13.6  Recommendations.  The  POSIX.lc  standard  is  not  ready  to  be  the  basis  for  early  Ada 
application  use.  The  standard  needs  an  Ada  binding,  and  the  Ada  binding  committee  needs  a  firm 
platform  to  resolve  the  threads  versus  tasks  issue. 
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Most  potential  portability  problems  concerning  Ada  and  Pthreads  will  have  to  be  resolved  by  the 
Ada  Binding  to  Pthreads. 
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3.8.1.14  Data  typing  services.  Because  POSIX  and  UNIX  files  are  simple  byte  streams,  with  no 
structure  imposed  on  them  by  the  O/S,  as  is  common  in  mainframe  environment,  the  type  of  data 
stored  in  a  file  must  be  tagged  in  some  way.  Common  methods  of  tagging  data  include  using  the 
file  name  suffix  as  an  indicator  (for  example,  ".c"  or  "tar")  or  writing  a  recognizable  header  in  the 
first  part  of  the  file  (so-called  "magic  numbers"). 

3.8.1.14.1  Standard.  Table  3.8-14  presents  standards  for  data  typing  services. 


TABLE  3.8-14  Data  typing  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPT 

1S0/IF.C 

Information  Technology  -  Portable  Operating  Syrian 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (at  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

XJOpc* 

Common  Dctktop  Environment  (CDE);  XCDE  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Opoi 

Common  Detktop  Environment  (CDE);  XCDE  Definition* 
and  Infrariractiue 

C324  (4/95) 

Mandated 

(Approved) 

BM1 

".'"'■'■y:":'  y‘ 1 ..  V,\' '  •  ^  'V"  '•Vr.V'.iy,  'V"..,/)' 

■Sli 

I..  1 

3.8.1.14.2  Alternative  specification.  The  following  specifications  are  also  available: 

a.  Berkeley  4.2/4.3  Unix. 

b.  OSFOSF/1. 

c.  Mortice  Kern  Systems'  MKS  Toolkit  ("file"  command). 

3.8.1.14.3  Standard  deficiencies.  The  "file"  command,  as  defined  by  POSIX,  does  not  provide 
for  user  definition  of  new  files  types. 

3.8.1.14.4  Portability  caveats.  All  of  the  alternative  specifications  provide  for  a  "magic"  file 
which  allows  new  file  types  to  be  defined.  Although  the  basic  format  of  this  file  is  the  same  for  all 
implementations,  there  are  minor  differences  between  them  which  hinder  the  sharing  of  this  file. 
POSIX.2b  is  attempting  to  remedy  this  by  defining  a  standard  format  for  the  magic  file,  but  no 
implementations  which  conform  to  this  draft  standard  exist. 

3.8.1.14.5  Related  standards.  None 

3.8.1.14.6  Recommendations.  180  9945-2  is  recommended.  If  user  configuration  is  required, 
conformance  to  the  draft  P1003.2b  standard  for  the  format  of  the  magic  file  is  recommended.  In 
a  GUI  environment,  the  XCDE  data  typing  services  are  recommended.  Data  typing  facilities  are 
inherent  in  the  format  of  the  OpenDoc  "Bento"  storage  structure. 
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3.8.1.15  Large  file  support.  As  UNIX  systems  have  become  increasingly  more  powerful,  a 
number  of  system  vendors  and  UNIX  independent  software  vendors  have  developed  a 
requirement  to  access  files  that  contain  more  information  than  can  be  addressed  using  a  signed 
long  integer.  A  number  of  system  vendors  and  users  have  been  meeting  at  the  "Large  File 
Summit"  to  develop  a  set  of  changes  to  the  existing  Single  UNIX  Specification  (SUS)  that  allow 
both  new  and  converted  programs  to  address  files  of  arbitrary  sizes.  This  set  of  changes  was 
included  in  the  latest  version  of  the  SUS.  In  addition,  a  set  of  transitional  extensions  intended  to 
permit  users  to  immediately  implement  large  file  support  on  typical  32-bit  UNIX  operating 
systems  has  been  included. 

3.8.1.15.1  Standards.  Table  3.8-15  presents  standards  for  targe  file  support. 


TABLE  3.8-15  Large  file  support  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Single  UNIX  Specification,  Syrian  Interface*  And  HeAden, 
Venion  2,  luueS 

C606  (2/97) 

Emerging 

(Approved) 

3.8.1.15.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.1.15.3  Standard  deficiencies.  Standards  deficiencies  are  unknown. 

3.8.1.15.4  Portability  caveats.  Portability  problems  with  existing  specifications  are  unknown. 

3.8.1.15.5  Related  standards.  Standards  related  to  large  file  support  are  unknown. 

3.8.1.15.6  Recommendations.  Users  with  a  requirement  to  create/access  large  files  should 
continue  to  monitor  the  actions  of  the  Large  File  Summit. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/1EC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open- specific  Threads  extensions  and  dynamic  linking. 

For  current  systems,  users  should  ensure  that  vendors  incorporate  the  set  of  extensions  to  the 
SUS  in  their  current  compliant  products. 
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3.8.1.16  Dynamic  linking.  Dynamic  linking  is  a  mechanism  that  allows  executable  code  to  be 
segmented  into  distinct  modules  called  dynamically  linked  libraries  (DLLs).  An  application  can, 
with  some  restrictions,  directly  call  the  functions  provided  by  a  DLL  after  linking  with  it 
Furthermore,  any  given  Dll  can  be  concurrently  linked  to  and  used  by  multiple  applications. 

3.8.1.16.1  Standards.  Table  3.8-16  presents  standards  for  dynamic  linking. 


TABLE  3.8-16  Dynamic  linking  standards 


Standard- 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Single  UNIX  Specification,  Command*  and  Utihtie*.  Iuue 

5,  VenioG  2 

C604  (2/97) 

Emerging 

(Approved) 

CPC 

X/Opeo 

Single  UNIX  Specification,  System  Interface  Definition*, 
Venion  2,  Iuue  5 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface*  and  Header*, 
Venion  2,  Iuue  5 

C606  (2/97) 

Emerging 

(Approved) 

3.8.1.16.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.1.16 .3  Standard  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.1.16.4  Portability  caveats.  Portability  is  a  problem  in  this  area  because  there  are  no 
established  standards. 

3.8.1.16.5  Related  standards.  There  are  no  related  standards. 

3.8.1.16.6  Recommendations.  Dynamic  linking  specifications  are  being  formalized  to  include  in 
the  next  version  of  the  Single  Unix  Specification. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard:  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSEX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8J  Media  handling.  Media  handling  refers  to  standards  for  disk  and  tape  formatting  for  data 
and  interchange  of  data  with  applications.  The  concept  of  layered  storage  is  not  described  in 
standards  documents.  However,  a  digital  data  interchange  (DDI)  reference  model  was  presented 
to  ANSI  X3/SPC  by  the  NIST  representative  to  X3  media  committees.  This  model  is  Level  4, 
Special  application  on  media;  Level  3,  Logical  format  for  media;  Level  2,  Physical  format  on 
media;  Level  1,  Media. 

3.8.2. 1  Backup  and  restore.  (This  BSA  appears  both  in  part  8  and  part  9.)  Backup  and  restore 
standards  provide  facilities  and  interfaces  to  save  data  as  a  precaution  to  system  failure  and 
restore  the  system  to  a  previous  data  state  after  failure. 

3.8.2.1.1  Standards.  Table  3.8-17  presents  standards  for  backup  and  restore. 


TABLE  3.8-17  Backup  and  restore  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISOARC 

9945-1:1996 

Mandated 

(Approved) 

IPC 

ISOAEC 

‘wnatiaa  Tc.-mul*.  *  vr.mting  System 

Iri'c-rfhoc  (POSIX)  -  Part  2;  Stw-i  .-«.*•  V>;  i  • » profiled 

by  FIPS  PUB  189;  tv”  • 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Op« 

Single  UNIX  Specification,  Command  uni  'jUtii.vJ,  is  Ate 

5,  Version  2 

G604 (297) 

Emerging 

(Approved) 

CPC 

NIST 

HI’S  PUD  151- 
2:1993 

Informational 

(Approved) 

NPC 

ANSI 

Recorded  Magnetic  Tape  for  Information  Interchange 
(1600  cpi,  Phase  Encoded) 

X3.  39-1986 
(R1992) 

Informational 

(Approved) 

NPC 

ANSI 

Recorded  Magnetic  Tape  for  Information  Interchange 
(6250  cpi,  Group-Coded  Recording) 

X3.  54-1986 
(R1992) 

Informational 

(Approved) 

CPC 
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OSF 

OSF/1  Operating  Sy  item 

OSF/1  O.S. 

Informational 

(Approved) 
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3.8.2.1.2  Alternative  specifications.  The  ”dd"  utility  is  useful  for  data  copy  with  optional 
conversion  that  promotes  portability,  (e.g.,  ASCII  to  EBCDIC)  or  for  record  conversion  with 
discrete  record  sizes,  or  multiple  sector  reads/writes  to  disk.  The  Berkeley  Unix  "dump" 
command  is  also  available.  The  OSFs  OSF/1  "tar"  and  "cpio"  utilities  and  USG's  System  V 
Release  4  (SVR4)  are  also  available. 
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3.8.2. 1.3  Standards  deficiencies.  Although  the  "tar”  and  "cpio"  commands  can  be  used  to  back 
up  disks,  they  are  very  limited  in  capability,  "tar"  and  "cpio"  are  copy  commands.  These 
commands  do  not  perform  incremental  backups.  Furthermore,  "tar"  does  not  span  multiple  disks. 
No  Ada  bindings  exist  for  distributed  backup  and  restore  standards. 

3.8.2. 1.4  Portability  caveats.  The  "ustar"  format  is  an  extension  of  the  historical  "tar"  archive 
format  and,  as  such,  may  be  read  by  historical  implementation  of  the  "tar"  command.  The 
POSIX.2  "pax"  command  has  been  developed  as  a  replacement  for  both  "tar"  and  "cpio" 
commands.  It  can  read  and  write  "ustar"  and  "cpio"  archives,  and  most  implementations  have 
been  extended  to  read  historical  "tar"  format  archives  as  well. 

The  "cpio"  command  can  produce  two  different  types  of  archives:  "character"and  "binary."  The 
binary  archives  are  non-portable,  and  cannot  be  read  except  on  the  same  platform  on  which  they 
were  produced.  POSIX  documents  only  the  character  "cpio"  format,  and  the  "pax"  command  is 
only  guaranteed  to  be  able  to  read  the  character  format. 

The  Berkeley  Unix-based  set  of  "backup"  commands  (e.g.,  "dump"  and  "rdump")  are  not  the 
same  as  the  backup  commands  based  on  System  V  (SVID)  (e.g.,  "backup,"  "bkexcept,”).  The 
two  backup  systems  have  different  interfaces  and  do  not  work  in  a  compatible  manner. 

3.8.2. 1.5  Related  standards.  The  following  standards  are  related  to  backup  and  restore  or 
backup  and  restore  standards. 

a.  ISO/1EC  9595:  CMIS. 

b.  ISO/IEC  9596:  CMIP. 

c.  ISO/IEC  DIS  11578.2:  RPC. 

d.  Network  Management  Forum:  OMNIPoint  1 . 

e.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  'or 
TCP/IP-based  Internets. 

f.  Internet  RFC  1 157:  Simple  Network  Management  Protocol. 

g.  Internet  RFC  1 158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

3.8.2.1.6  Recommendations.  ISO/IEC  9945-1  and  ISO/IEC  9945-2  archiving  services  are 
recommended.  The  operating  system  standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC 
9945-1:1990,  IEEE  1003. 1  b:  1 993,  IEEE  1 003.  lc:  1 995,  and  IEEE  1003. 1  i:  1 995)  are  all 
incorporated  in  the  new  ISO/IEC  9945-1:1996.  Federal  Information  Processing  Standard  (FIPS) 
151-2  should  also  be  consulted.  It  adopted  ISO  9945- 1 : 1 990  and  is  still  applicable  to  the  1 996 
version.  "Pax"  was  commissioned  for  POSIX.2  because  "tar"  and  "cpio"  were  considered 
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inadequate.  "Pax"  is  similar  to  "tar"  and  "cpio."  The  "tar"  and  "cpio"  formats  are  expected  to  be 
retired  from  a  future  version  of  POSIX.  1  in  favor  of  the  newer  "ustar"  format 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.2 2  Floppy  disk  format  and  handling.  (This  BSA  appears  both  in  part  8  and  part  9.) 
Floppy  disk  format  and  handling  standards  provide  formats  and  interfaces  for  the  exchange, 
backup,  and  restoration  of  data  to  or  from  floppy  disks. 

3.8.2. 2.1  Standards.  Table  3.8-18  presents  standards  for  floppy  disk  format  and  handling. 


TABLE  3.8-18  Floppy  disk  format  and  handling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  1: 
Syitem  API  (Replace*  ISO  9945- 1 : 1990  and  incorporate* 
IEEE  1003.1b.  1003.1c.  and  1003.li) 

9945-1:1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Portable  Operating  Syitem 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (a*  profiled 
bv  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphic*  Device  Interface, 
Volume  1  Microsoft  Win32  Programmer*'  Reference 
Manual,  1993.  Micro*oft  Pre*» 

Win32  API* 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  Command*  and  Utilise*,  lime 

5,  Venion  2 

C604  (2/97) 

Emerging 

(Approved) 

CPC 

NIST 
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Informational 

(Approved) 
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3.8.2. 2. 2  Alternative  specifications.  The  following  alternative  specifications  are  also  available: 

a.  Sun  Microsystems'  SunOS/Solaris  command  "bar" 

b.  OSF:  OSF/1  "tar"  and  "cpio”  utilities. 

3.8.2.2.3  Standards  deficiencies.  POSIX  and  Unix  have  very  poor  floppy  disk  handling 
capabilities.  Most  standards  related  to  floppy  disks  concern  logical  interfaces  that  permit  the 
interconnection  of  floppy  disk  peripherals. 

3.8.2.2.4  Portability  caveats.  The  "bar"  is  not  a  standard.  However,  it  is  widely  used  because  of 
Sun's  large  installed  base.  It  is  presented  as  an  example  of  a  capability  needing  to  be  standardized, 
as  well  as  an  example  of  the  kind  of  capability  that  could  be  specified, 

3.8.2.2.5  Related  standards.  No  standards  are  related  to  floppy  disk  format  standards. 
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3A2.2.6  Recommendations.  ISO/IEC  9945-2  disk  format  services  "pax"  are  expected  to  replace 
"tar"  and  "cpio"  utilities  in  POSIX.  1. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/TEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3A.23  POSIX  tape  labeling  and  tape  volume  processing.  (This  BSA  appears  both  in  part  8 
and  part  9.)  Tape  labels  are  a  fixed  portion  of  data  stored  on  tape  media  and  containing  certain 
types  of  administrative  information  automatically  readable  by  tape-handling  software.  Among  the 
information  typically  stored  on  tape  labels  are  the  identification  of  the  media  content,  ownership 
of  the  media  content,  access  control  information  for  the  media  content,  and  the  format  of  the  rest 
of  the  information  on  the  media. 

3.8.2. 3. 1  Standards.  Table  3.8-19  presents  standards  for  POSIX  tape  labeling  and  tape  volume 
processing. 


TABLE  3.8-19  POSIX  tape  labeling  and  tape  volume  processing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pem 

IPC 

ECMA 

File  Structure  and  Labeling  of  Magnetic  Tape*  for 
Information  Interchange 

13 (1985) 

Informational 

(Approved) 

IPC 

ECMA 

Magnetic  Tape  Can ette  Labeling  and  File  Structure  for 
Information  Interchange 

41 (1973) 

Informational 

(Approved) 
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3.8.2J.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.8.2.3.3  Standards  deficiencies.  The  P1003.1a  draft  standard  does  not  address  the  issue  of 
processing  several  files  as  if  they  were  a  single  entity. 

Traditional  Unix  systems  do  not  provide  mechanisms  for  protected  access  to  devices  or  media, 
nor  do  they  encrally  provide  mechanisms  for  label  processing  or  transparent  volume  switching. 

3.8.2.3.4  Portability  caveats.  To  provide  tape  handling  portability,  a  standard  must  specify  the 
handling  of  ANSI/ISO  labeled  tape  and  IBM  labeled  tape.  IBM  labeled  tapes,  although  not  a 
strict  standard,  represent  vast  numbers  of  labeled  tapes  already  in  existence.  IBM  labeled  tapes 
are  roughly  analogous  to  the  ANSI  standard,  except  the  labels  are  written  with  the  EBCDIC 
character  set  rather  than  with  ASCII. 

It  is  not  certain,  even  within  the  proposed  standard,  how  to  process  information  when  some  of  it 
is  on  9-track  tape  and  some  on  8mm  (Exabyte)  tape,  or  some  on  labeled  and  some  on  ur.labeled 
tape.  This  may  be  a  limitation  of  the  standard. 

3.8.2.3.5  Related  standards.  The  following  standards  are  related  to  POSIX  tape  labeling  and 
tape  volume  processing  standards: 

a.  ISO/IEC  9945- 1 : 1996:  POSIX  Part  1:  System  Application  Programming  Interface. 

b.  ISO/IEC  9945-2:1992:  POSIX  Part  2:  Shell  and  Utility. 
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c.  IEEE  1003.5: 1992:  Ada  Language  Binding  to  POSDC. 

d.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

e.  IEEE  P1387.1:  POSIX  System  Administration  -  Part  1:  Overview. 

f.  IEEE  1003.9: 1992:  Standard  Fortran  Language  Bindings  to  POSIX. 

3.8.2.3.6  Recommendations.  There  are  no  recommendations. 
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3.S.2.4  Data  interchange  format.  Data  interchange  file  format  is  the  format  of  files  to  be  copied 
from  a  medium  to  the  file  hierarchy  and  from  the  file  hierarchy  to  a  medium. 

3.8.2.4.1  Standards.  Table  3.8-20  presents  standards  for  data  interchange  format. 


TABLE  3.8-20  Data  interchange  format  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  I: 
System  API  (Replaces  ISO  9945*  l :  1990  Mid  incorporate! 
IEEE  1003.1b.  1003.1c.  and  1003.lt) 

9945-1:1996 

Mandated 

(Approved) 

NPC 

fTTFP 

Portable  Operating  Syitem  Interface  (POSIX)  -  Part  1: 
Syitem  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

TFFF 

POSIX  Part  1 :  Syitem  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  [C  Language) 

1003.  ti:  1995 

Informational 

(Approved) 

3.8. 2.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.8.2.4 3  Standards  deficiencies.  Standards  deficiencies  are  unknown. 

3.8.2.4.4  Portability  caveats.  The  "ustar"  format  is  an  extension  of  the  historical  "tar"  archive 
format  and,  as  such,  may  be  read  by  historical  implementation  of  the  "tar"  command.  The 
POSEX.2  "pax"  command  has  been  developed  as  a  replacement  for  both  "tar"  and  "cpio" 
commands.  It  can  read  and  write  "ustar"  and  "cpio"  archives,  and  most  implementations  have 
been  extended  to  read  historical  "tar"  format  archives  as  well. 

The  "cpio"  command  can  produce  two  different  types  of  archives:  "character"and  "binary."  The 
binary  archives  are  non-portable,  and  cannot  be  read  except  on  the  same  platform  on  which  they 
were  produced.  POS1X  documents  only  the  character  "cpio"  format,  and  the  "pax"  command  is 
only  guaranteed  to  be  able  to  read  the  character  format. 

3.8.2.4.5  Related  standards.  There  are  no  related  standards. 

3.8.2.4.6  Recommendations.  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003.1b  is 
recommended. 
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3.8.3  Shell  and  utilities.  A  user's  shell  is  the  interface  to  the  operating  system.  Simple  shells 
enable  the  user  to  control  the  environment  and  run  programs.  Traditionally,  shells  have  been 
command-line  oriented,  and  have  provided  simple  programming  facilities,  allowing  them  to  double 
as  “job  control  languages."  Recently,  GUI  and  menu  driven  shells  have  become  available, 
eliminating  the  need  to  learn  complicated  command  lines  to  perform  everyday  tasks  like  reading 
mail  or  managing  a  calendar. 

Commands  and  utilities  include  mechanisms  for  operations  at  the  operator  level,  such  as 
comparing,  printing,  and  displaying  file  contents;  editing  files,  searching  patterns;  evaluating 
expressions;  logging  messages;  moving  files  between  directories;  sorting  data;  executing 
command  scripts;  scheduling  signal  execution  processes;  and  accessing  environment  information. 

3.8.3.1  Commands  and  utilities  used  in  applications  and  shell  scripts.  A  shell  script  is  a  file 
of  executable  UNIX  commands  created  by  a  text  editor  and  made  executable  with  the  "chmod" 
command.  These  standards  refer  to  the  commands  and  utilities  of  the  operating  system  used  in 
the  script. 

3.8.3. 1.1  Standards.  Table  3.8-21  presents  standards  for  commands  and  utilities  used  in 
applications  and  shell  scripts. 


TABLE  3.8-21  Commands  and  utilities  used  in  applications  and  shell  scripts  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hi 

1PC 

ISO/IEC 

Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilidea  (a*  profiled 
FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDE  Service! 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Deiktop  Environment  (CDE);  XCDE  Definition* 

and  Infrastructure 

C324  (4/95) 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  Commands  and  Utilities,  Issue 

5,  Venion  2 

C604  (2/97) 

Emerging 

(Approved) 
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3.8.3.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 
a.  Berkeley  4.2/4.3  Unix. 
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b.  GNU  Utilities  (Public  domain  utilities  from  the  Free  Software  Foundation). 

c.  OSF:  OSF/1, 

d.  Mortice  Kern  Systems  Inc.'s  MKS  Toolkit  a  toolkit  with  POSIX.2  and  POSIX.2a 
compliant  shell,  tools,  and  utilities,  as  well  as  other  traditional  Unix  language  tools 
and  utilities  for  Unix  and  DOS  computers,  which  is  being  implemented  widely  on 
proprietary  operating  systems, 

3.8.3.1.3  Standards  deficiencies.  POSIX.2  lacks  many  of  the  advanced  commands  and  utilities 
present  in  XPG4,  the  SVID,  and  OSF/1,  such  as  "chroot,"  "col,"  "cancel,"  "atq,"  "dircmp,"  "fmt," 
"egrcp,"  "line,"  "mktemp,"  "nl,"  "passwd,"  and  "curses". 

POSIX.2  commands  and  utilities  lack  many  of  the  options  for  the  commands  also  present  in 
XPG4,  the  SVID,  and  OSF/1 . 

3.8.3.1.4  Portability  caveats.  POSIX.2  is  not  quite  compatible  with  many  of  the  supposedly 
same  utilities  in  XPG4,  the  SVID,  or  OSF/1,  because  even  though  the  command  names  are  the 
same,  the  commands  have  different  options.  The  1003.2  standard  is  not  the  same  as  the  Bourne 
shell. 

Since  XPG4,  version  2  (the  Single  Unix  Specification)  has  been  aligned  with  POSIX.2,  POSIX.2 
may  be  considered  a  "lowest  common  denominator"  for  future  releases  of  proprietary  Unix 
platforms  like  Solaris  and  HP-UX. 

3.8.3.1.5  Related  standards.  The  following  standards  are  related  to  commands  and  utilities  used 
in  applications  and  shell  scripts: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POS1X. 

b.  IEEE  1003.2d:1994:  POSIX  Batch  Environment  Amendments. 

3.8.3.1.6  Recommendations.  The  interfaces  to  desired  commands  and  utilities,  which  POSIX 
lacks,  also  must  be  identified  and  explicitly  specified  in  procurements.  The  procurement's 
interface  specification  must  include  each  command's  options  and  syntax  (e.g.,  order  of  the 
options,  if  applicable),  in  addition  to  the  name  of  the  command  and  the  service  it  provides. 

The  following  wording  is  recommended  as  part  of  the  specification  for  these  services: 

"Commands  and  utilities  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall 
conform  to  the  requirements  in  the  NIST  FIPS  189  on  POSIX  Command  and  Utility  Application 
Interface  for  Computer  Operating  System  Environments,  defined  in  ISO/1EC  9945-2  (POSIX: 
Part  2:  Shell  and  Utilities)." 

In  many  cases,  it  will  be  necessary  to  supplement  the  POSIX.2  commands  and  utilities  to  meet  a 
procurement's  needs.  If  possible,  identify  the  most  important  commands  and  utilities  lacking  in 
POSIX.2,  whose  use  is  anticipated  to  be  widespread  across  many  procurements,  and  standardize 
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around  these  internally  for  all  procurements.  Otherwise,  no  backward  compatibility  will  be 
present  with  systems  not  supporting  these  commands,  and  no  portability  across  systems 
supporting  these  commands  in  different  ways.  If  the  commands  required  are  part  of  XPG4,  then 
conformance  to  Single  Unix  should  be  specified. 

Aside  from  specifying  GUI  behavior  and  commands,  XCDE  also  defines  command  line  interfaces 
to  this  functionality  (principally  in  order  to  "launch"  the  environment).  XCDE  is  recommended 
for  environments  which  require  GUI  functionality. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POS1X.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSDC;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3A.32  Shell  programming  language.  The  shell  programming  language  is  a  high-level 
programming  language  that  can  use  operating  system  commands  and  utilities  to  build  applications 
and  shell  scripts. 

3.8.3. 2.1  Standards.  Table  3.8-22  presents  standards  for  shell  programming  languages. 


TABLE  3.8-22  Shell  programming  language  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/EC 

Information  Technology  -  Portable  Operating  Syfttem 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (ai  profiled 
bv  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Detktop  Environment  (CDE);  XCDE  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  Command*  and  UtiBtie*,  Iieue 

S,  Vernon  2 

C604  (2/97) 

Emerging 

(Approved) 

MM 

lllili 

1 
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. 
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3.8.3.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  Unix. 

b.  GNU  Bourne  Again  Shell  (Korn  Shell  Imitation  with  job  control)  (Public  Domain). 

c.  Mortice  Kern  Systems  Inc.'s  POS1X.2-  and  POSIX.2a-compliant  MKS  Toolkit. 

d.  OSF:  OSF/1  C  Shell  (csh),  Korn  Shell  (ksh),  Remote  Shell  (rsh),  Restricted  Shell 
(rsh,  Rsh). 

3.8.3.2.3  Standards  deficiencies.  The  System  V  Bourne  shell  lacks  easy  arithmetic  and  substring 
manipulation  capabilities,  the  tilde  expansion,  and  easy  command  substitution  nesting. 

3.5.3.2.4  Portability  caveats.  Shell  scripts  written  under  different  shells  are  not  portable  to  other 
shells.  POSIX.2  extended  the  System  V  Bourne  shell  with  features  from  the  Korn  shell  to  correct 
historical  deficiencies  (e.g.,  those  listed  under  standards  deficiencies),  as  well  as  extending  it  with 
the  Korn  shell's  interactive  features  for  command-line  editing. 
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3A3.2JS  Related  standards.  The  following  standards  are  related  to  shell  programming  languages 
or  shell  programming  language  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

b.  IEEE  1003.2d:1994:  POSIX  Batch  Environment  Amendments. 

3.8.3.2.6  Recommendations.  Several  shell  features  are  not  required  by  FIPS  189.  These  are: 

a.  Operators  (( )) 

b.  Reserved  words  [[  ]] 

c.  Substring  expansions 

$name#pattem 

$name%pattem 

$name##pattem 

$name%%pattem 

d.  String  length  expansion  $#name 

e.  Command  substitution  syntax  $(command) 

f.  Multi  digit  positional  parameters 

g.  Assigning  values  with  "export"  and  "readonly” 

h.  Separation  of  positional  parameters  expanded  from  $*  and  $@  by  the  first 
character  of  the  IFS.  Only  the  capability  to  separate  parameters  by  a  space  is 
required. 

i.  Functions 

j.  Function  option  ”-f  ’  for  the  "unset"  command 

k.  The  built-in  commands  "alias"  (to  define  and  display  aliases)  and  "unalias"  (to 
remove  the  aliases  defined) 

The  following  wording  is  recommended  for  specifying  shell  programming  language  services: 

"Shell  invocation  primitives  and  built-in  commands  offered  as  a  result  of  the  requirements  of 
which  this  is  a  part  shall  conform  to  the  requirements  in  the  NIST  189  FIPS  on  POSIX  Command 
and  Utility  Application  Interface  for  Computer  Operating  System  Environments,  defined  in 
ISO/IEC  9945-2  (POSIX:  Part  2:  Shell  and  Utilities)." 
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Since  portability  is  the  goal,  avoid  the  use  of  the  multiple,  historical  shells  in  favor  of  the  POS1X.2 
shell. 

X/Open  Single  Unix  Specification  provides  additional  utilities.  XCDE  is  recommended  for 
environments  that  require  GUI  functionality. 

Issue  S  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSEX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3JSJ J  User-oriented  commands  and  utilities.  User-oriented  commands  and  utilities  are 
miscellaneous  facilities  used  by  end-users,  programmers,  and  system  operators  to  perform  an 
action  on  an  immediate  personal  basis. 

3.8.3.3.1  Standards.  Table  3.8-23  presents  standards  for  user-oriented  commands  and  utilities. 


TABLE  3.8-23  User-oriented  commands  and  utilities  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Information  Technology  -  Portable  Operating  System 
Interface  (POSDf)  -  Part  2:  Shell  and  Utilities  (as  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Opeo 

Common  Desktop  Environment  (CDE);  XCDB  Services 
and  Applications 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Opctt 

Single  UNIX  Specification,  Commands  and  Utilities,  issue 

5,  Version  2 

C604  (2/97) 

Emerging 

(Approved) 

liliill 

JjjjjjJ 
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jKiiiBi 
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3.5.3.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  Unix. 

b.  GNU  Utilities  (Public  Domain  Programs  from  the  Free  Software  Foundation). 

c.  Mortice  Kern  Systems  Inc.'s  POSDC.2-  and  POSIX.2a-compliant  MKS  Toolkit. 

d.  OSF:  OSF/1. 

3.8.3.3.3  Standards  deficiencies.  POSLX.2  lacks  many  of  the  utilities  present  in  XPG4,  SV1D, 
and  OSF/1,  such  as  "banner,"  "calendar,"  "help,"  "learn,"  and  "spell."  POSIX.2  utilities  lack  many 
of  the  options  present  in  XPG4,  the  SVID,  and  OSF/1. 

3.8.3. 3.4  Portability  caveats.  POSIX.2  is  compatible  with  the  utilities  in  XPG4,  SVID,  or  OSF/1 
when  the  commands  are  used  with  no  options,  otherwise,  compatibility  is  not  guaranteed.  Since 
the  Single  Unix  Specification  (Spec  1 170)  has  aligned  the  XPG4  Commands  and  Utilities  with 
POSIX.2,  it  is  possible  to  consider  POSIX.2  a  "lowest  common  denominator"  among  systems 
that  conform  to  Spec  1 170. 

3.8.3.3.5  Related  standards.  The  following  standards  are  related  to  user-oriented  commands  and 
utilities: 
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a.  ISO/IEC  9945-1:  19%  POSIX  Part  1:  System  Application  Programming 
Interfaces. 

b.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  1003.2d:  1994:  POSIX  Batch  Environment  Amendments. 

3.8.3 3.6  Recommendations.  The  interfaces  with  desired  commands  and  utilities,  which  POSIX 
lacks,  also  must  be  identified  and  specified  explicitly  in  procurements.  The  procurement's 
interface  specification  must  include  each  command's  options  and  syntax  (e.g.,  order  of  the 
options,  if  applicable),  in  addition  to  the  command  name  and  the  service  it  provides. 

The  following  wording  is  recommended  for  specifying  user-oriented  commands  and  utilities: 

"Commands  and  utilities  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall 
conform  to  the  requirements  in  the  NIST  FIPS  189  on  POSIX  Command  and  Utility  Application 
interlace  for  Computer  Operating  System  Environments,  defined  in  ISO/IEC  9945-2  (POSIX: 

Part  2:  Shell  and  Utilities)." 

In  many  cases,  the  POSIX.2  commands  and  utilities  will  need  to  be  supplemented  to  meet  a 
procurement's  needs.  To  maximize  portability,  identify  the  most  important  user  portability 
extension  commands  lacking  in  POSIX.2  whose  use  is  anticipated  to  be  widespread  across  many 
procurements,  and  standardize  around  these  internally  for  all  procurements.  Otherwise,  there  will 
be  no  backward  compatibility  with  systems  not  supporting  these  commands,  and  no  portability 
across  systems  supporting  these  commands  in  different  ways. 

Specifying  Single  Unix  Specification  rather  than  POSIX.2  will  eliminate  the  problems  of  non¬ 
portable  extensions  to  POSIX.2  by  ensuring  that  all  systems  procured  include  the  same 
extensions. 

XCDE  provides  a  variety  of  user-oriented  utilities  related  to  file  management,  printing,  and 
editing.  The  "drag  and  drop"  functionality  specified  by  XCDE  is  a  graphical  method  of  providing 
arguments  to  programs.  By  dragging  a  GUI  object  and  "dropping"  it  on  another  object,  the  user 
instructs  the  target  object  to  operate  on  the  dropped  object  in  an  appropriate  manner.  For 
example,  dropping  a  file  on  a  printer  icon  would  cause  the  file  to  be  printed,  but  dropping  a  file  on 
a  directory  in  the  file  manager  would  cause  the  file  to  be  moved,  or  copied. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3X3.4  File  and  prog  ran.  editing  services.  File  and  program  editing  services  refer  to  interactive 
editors,  stream  editors,  and  utilities  for  editing  tiles  and  programs,  and  specialized  programming 
languages  that  often  are  used  for  editing. 

3.8.3.4.1  Standards.  Table  3.8-24  presents  standards  for  file  and  program  editing  services. 


TABLE  3.8-24  File  and  program  editing  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Information  Technology  -  Ported  Operating  System 
Interface  (POSIX)  -  Put  2:  Shell  and  Utilities  (w  profited 
by  FIPS  PTJB  189:1994) 

9945-2:1993 

Maodated 

(Approved) 

CPC 

X/Ope* 

Common  Desktop  Environment  (CDE);  XCDE  Services 
and  Applications 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Opt* 

Single  UNIX  Specification,  Commands  and  Utilities,  Issue 
5,  Version  2 

C604  (2/97) 

Emerging 

(Approved) 

' 
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3.8.3.4.2  Alternative  specifications.  Dozens  of  proprietary  editors  are  available,  among  the 
alternative  specifications  are  the  follwir.g  : 

a.  GNU  Emacs  from  the  Free  Software  Foundation. 

b.  OSF:  OSF/1  's  red  (restricted  line  editor),  view  (read-only  screen  editor),  vedit 
(beginner's  version  of  editor). 

3.8.3.4J  Standards  deficiencies.  The  editors  are  not  deficient.  Different  users  merely  prefer 
different  editors. 

3.8.3.4.4  Portability  caveats.  The  portability  issue  involving  editors  is  a  matter  of  user 
portability.  Each  editor  has  its  own  interface  that  users  must  learn  as  they  move  between  editors. 
However,  editors  do  not  affect  application  portability. 

3.8.3.4.5  Related  standards.  The  following  standards  are  related  to  file  and  program  editing 
services  standards: 

a.  IEEE  PI003.1e:  Security  Interface  Standards  for  POSIX. 

b.  IEEE  1 003.2d:  1 994:  POSIX  Batch  Environment  Amendments. 
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3JL3.4.6  Recommendations.  ISO/IEC  9945-2  (as  adopted  by  FIPS  189)  is  recommended  for 
text  and  stream  editors  to  obtain  POSIX  conforming  editing  services.  (While  this  is  not  critical 
for  application  portability,  the  increase  in  user  portability  will  save  both  time  and  money  in 
(re)training.) 

For  GUI  environments,  XCDE  is  recommended  as  well  as  FIPS  1 89. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  Fib  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3X3.5  Print  management.  (This  BSA  appears  both  in  part  8  and  part  9.)  The  print  services  are 
used  by  management  and  user  applications  to  send  a  file  to  the  printer,  cancel  the  print  job,  and 
get  printer  status  information.  The  printing  systems  program  interface  is  used  as  the  base  for  the 
POSLX  printing  management  standard.  Printing  management  standards  also  provide  services  and 
interfaces  for  transparent  remote  printing,  output  spooling,  spool  queue  management,  and 
scheduling. 

3.8.3.5.1  Standards.  Table  3.8-25  presents  standards  for  print  management 


TABLE  3X25  Print  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mu 

[PC 

ISO/1EC 

Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  -  Part  2:  Shell  aod  Utilities  (a*  profiled 
bv  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDF.  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphic*  Device  Interface, 
Volume  1  Microsoft  Win32  Programmer*’  Reference 
Manual,  1993.  Microsoft  Pit** 

Win32  APIs 

Mandated 

(Approved) 

_  CPC 

X/Ojx* 

Single  UNIX  Specification,  Command*  and  Utilities,  Issue 

5,  Version  2 

C604  (2/97) 

Emerging 

(Approved) 

[PC 

ECMA 

Method  for  Measuring  Printer  Throughput 

132(1991) 

Informational 

(Approved) 

1PC 

ISO/IEC 

Information  Technology  -  Text  and  office  systems  - 
Document  Printing  Application  (DP A),  Part  1:  Abstract 
service  definition  and  procedure* 

10175-1:1996 

Informational 

(Approved) 

[PC 

ISO/IEC 

Information  Technology  -  Text  and  office  systems  • 
Document  Printing  Application  (DP A)  -  Part  2:  Protocol 
specification 

10175-2:1996 

Informational 

(Approved) 
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3.S.3.5.2  Al'.-inative  specifications.  The  following  specifications  are  also  available; 

a.  MIT:  Palladium  (the  basis  for  DME  print  management). 

b.  Berkeley  4.2/4.3  Unix. 

c.  Siemens/Nixdorf:  Printing  Management  (the  basis  for  UI’s  distributed  printing 
management  specification  and  USL’s  reference  implementation). 
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3JJ.3.5.3  Standards  deficiencies.  SVID,  OSF/I,  and  Berkeley  Unix  have  no  features  to  control 
the  formatting  or  scheduling  of  print  jobs.  The  SVID,  OSF/1,  and  Berkeley  Unix  are  designed  for 
centralized  environments.  No  Ada  bindings  exist  for  prim  management  standards.  POSIX.2 
specifies  only  a  minimal  "lp"  command,  suitable  for  submitting  print  jobs;  no  printer 
administration  facilities  are  provided. 

3.8.3.5.4  Portability  cavaats.  The  System  V  Unix  "lp”  printing  system,  from  which  the  POSIX 
"lp"  command  is  derived,  is  not  compatible  with  the  Berkeley  Unix  "lpr"  printing  system. 

The  OSF  DME  distributed  print  management  is  based  on  MITs  Palladium.  It  has  a  different 
interface  from  UI/USL's  distributed  print  management,  which  is  based  on  the  Siemens-Nixdorf 
Xprint  program  and,  therefore,  is  incompatible. 

3.8.3.5 .5  Related  standards.  The  following  standards  are  related  to  print  management  services 
or  standards: 


a.  ISO/IEC  9945-1:1996;  POSIX  Part  1  -  System  Application  Programming 
Interface. 

b.  ISO  8824:1990:  Abstract  Syntax  Notation  1  (ASN.l). 

c.  ISO  8825:1990:  Basic  Encoding  Rules  for  ASN.l. 

d.  ISO  9072: 1989:  Remote  Operations  Service  Element  (ROSE). 

e.  ISO/IEC  9595: '  ommon  Management  Information  Service  (CMIS). 

f.  ISO/IEC  9596:  Common  Management  Information  Protocol  (CMIP). 

g.  ISO/IEC  DIS  1 1578.2:  Remote  Procedure  Call. 

h.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

i.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

j.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

k.  Internet  RFC  1 158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

l.  Network  Management  Forum:  OMNIPoint  1. 
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3JL3J.6  Recommendations.  The  recommendation  is  to  specify  POSDC  "lp"  only  for  traditional, 
centralized  systems  for  imminent  procurements.  Then  look  to  ISO  10175  or  IEEE  1387.4  in  the 
longterm. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8J.6  Batch  scheduling.  (This  BSA  appears  both  in  part  8  and  part  9.)  Batch  scheduling  refers 
to  the  ability  to  submit  jobs  to  be  executed  when  the  system  load  permits.  The  "at"  command 
allows  jobs  to  be  executed  at  a  predefined  time.  Batch  queuing  refers  to  the  ability  to  place 
multiple  jobs  in  a  queue  for  processing,  and  to  access  and  manage  the  queue. 

3.8.3.6.1  Standards.  Table  3.8-26  presents  standards  for  batch  scheduling. 


TABLE  3.8-26  Batch  scheduling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

IPC 

ISO/EC 

Information  Technology  -  Portable  Operating  Syilem 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilitie*  (a*  profiled 
by  FIPS  PUB  189:1994) 

99.  <-2:1993 

Mandated 

(Approved) 

NPC 

IPFF. 

Portable  Operating  System  Interface  (POSIX)  -  Part  2:Shell 
and  Utilitie*  -  Amendment  1:  Batch  Environment 

1003.2d:1994 

Mandated 

(Approved) 

IPC 

ISO/IEC 

OSI  System*  Management,  Part  IS:  Scheduling  Function 

10164-13:1995 

Informational 

(Approved) 

CPC 

X/Op Ml 

Single  UNIX  Specification,  Command*  and  Utilitie*,  luue 

5,  Version  2 

C604  (2/97) 

Emerging 

(Approved) 

CPC 

OSF 

GSF/1  Operating  System 

GSF/1  O.S. 

Informational 

(Approved) 
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3. 8.3.6. 2  Alternative  specifications.  The  Berkeley  BSD  4.3  Unix  "at"  and  "batch"  commands  are 
also  available. 

3.8.3.6.3  Standards  deficiencies.  The  POSIX.2  and  Unix  "at"  and  "batch"  commands  are 
designed  for  a  single  machine,  centralized  environment  Traditional  POSIX  and  Unix  batch 
capabilities,  such  as  "at"  and  "batch,"  are  inadequate  and  inefficient  for  managing  resources  and 
scheduling  jobs  in  many  environments,  particularly  environments  that  manage  expensive 
resources,  because  they  are  very  limited.  For  example,  "at"  allows  users  only  to  schedule 
machines  to  run  jobs  at  particular  times.  No  Ada  bindings  exist  for  the  POSIX. 2d  Batch  Queuing 
Extensions. 

3.5.3.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  spec '6  ations  are 
unknown. 

3.8.3.6.5  Related  standards.  No  standards  are  related  to  batch  scheduling. 

3.8.3.6.6  Recommendations.  The  mandated  standards  are  recommended,  but  both  provide  only 
limited  batch  functionality.  For  international  work,  use  the  POSIX.2  standard's  new  "-t  time" 
option  for  the  "at"  command  to  express  a  time  for  execution  of  the  submitted  job  in  a  way  to 
support  other  time  conventions  more  easily. 
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Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSDC;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8J.7  Language  bindings  to  POSIX.2.  These  standards  provide  programming  language 
interfaces  to  operating  system  shell  &  utilities. 

3.8 J. 7.1  Standards.  Table  3.8-27  presents  standards  for  language  bindings  to  POSIX.2. 


TABLE3.8-27  Language  bindings  to  POSIX.2  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

IPC 

ISO/IEC 

Information  Technology  •  Portable  Operating  Syrian 
Interface  (POSIX)  -  Put  2:  SheiJ  and  Utilities  (u  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Killed 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface*  and  Headers, 

Venion  2,  Iaauo  5 

C6fS  (2/97) 

Emerging 

(Approved) 

ms 

1 

""3SSWKT 

S53 

3.8.3.7.2  Alternative  specifications.  All  other  consortia  or  de  facto  specifications  include  C 
bindings. 

3.8.3.7  .3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.3.7.4  Portability  caveats.  The  interpretation  of  the  C  bindings  for  other  programming 
languages  probably  will  result  in  some  misinterpretations,  which  in  turn,  will  result  in  some 
portability  problems  due  to  different  interpretations  and  assumptions  in  the  original  C  language 
binding. 

3.8.3.7.5  Related  standards.  The  following  standards  are  related  to  language  bindings  to 
POSIX.2; 


a.  IEEE  1003.5:1992:  Ada  Language  Binding  tor  POS1X. 

b.  IEEE  1003.9: 1992:  Standard  Fortran  Language  Bindings  to  POSIX. 

3.8.3.7.6  Recommendations.  1SO/IEC  9945-2  (as  adopted  by  FIPS  189)  is  recommended  for  its 
POSIX.2  language  binding,  although  it  is  limited  to  C. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specifio  Threads  extensions  and  dynamic  linking. 
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3JL3.8  User-oriented  mail  services.  One  of  the  most  important  services  provided  by  a  computer 
system  is  electronic  mail. 

3.&3.8.1  Standard.  Table  3.8-28  presents  standards  for  user-oriented  mail  services. 


TABLE  3.8-28  User-oriented  mail  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

1SOAEC 

Information  Technology  -  Portable  Operating  Syatem 
Interface  (POSDQ  -  Put  2:  Shell  and  Utilibea  (at  profiled 
by  FIPS  PUB  1*9:1994) 

9945-2:1993 

Maodatod 

(Approved) 

CPC 

X/Optti 

Common  Desktop  Environment  (CDE);  XCDE  Service* 
and  Application* 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Optn 

Single  UNIX  Specification,  Command*  and  Utilitied,  Iiaue 

5,  Venton  2 

C604  (2/97) 

Emerging 

(Approved) 

— jsareso- 

Ikiiai 

3JJ.3.8.2  Alternative  specification.  The  following  specifications  are  also  available: 

a.  OSF:  OSF/1 

b.  Berkeley  BSD  4.3/4.4  Unix  "Mail"  command 

c.  Berkeley  BSD  4.3/4.4  Unix,  MH  message  handling  system  (sot  related  to  OSI 
MHS  functionality) 

3.8. 3.8.3  Standard  deficiencies.  None  of  the  standards  listed  explicitly  discuss  inter-machine 
communication.  The  ability  to  send  mail  to  users  on  remote  systems  requires  the  appropriate 
n;  'work  services  standards  (see  "related  standards"  below). 

3.8.3.8.4  Portability  caveats.  None 

3.5.3.8.5  Related  standards.  The  following  standards  are  related  to  electronic  mail  services: 

a.  Internet  SID- 10:  Simple  mail  transfer  protocol  (SMTP)  (RFC  821). 

b.  Internet  STD- 1 1 :  Format  for  Electronic  Mail  Messages  (RFC  822). 

c.  ISO/IEC  9594  (nine  parts  plus  two  draft  parts):  OSI  -  -  The  Directory. 

d.  ISO/IEC  10021  (nine  parts):  Text  Communication  -  Message-oriented  text 
interchange  systems  (MOT1S)  and  Message  handling  systems  (MHS). 
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3.8.3.8.6  Recommendations.  Because  the  user  interface  must  properly  interact  with  the  network 
services,  making  recommendations  in  this  area  is  difficult  For  example,  there  are  no  known 
implementations  of  the  POSIX.2  mailx  command  which  will  properly  communicate  with  an  OSI- 
based  network  mail  service. 

POSIX.2  is  recommended  for  command-line  based  environments.  XCDE  Mail  Services  is 
recommended  for  GUI  environments. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard:  C  Language  Binding:  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  flies  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3X3.9  Time  management  services.  Time  management  services  allow  both  individuals  and 
groups  of  people  to  control  their  time  more  effectively  by  providing  functions  to  schedule 
meetings  via  a  simple  browsable  and  updateable  interface;  access  group  members  schedules;  and 
create  and  edit  individual,  project,  or  departmental  "todo  lists”.  Advanced  implementations  will 
provide  privacy  and  authorization  to  ensure  that  people  cannot  see  more  information  than  they're 
permitted  and  to  restrict  the  ability  to  modify  the  schedules  of  other  people. 

3X3.9.1  Standard.  Table  3.8-29  presents  standards  for  time  management  services. 


TABLE  3.8-29  Time  management  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

X/Opefl 

Common  Desktop  Environment  (CDE);  XCDE  Serviced 
and  Applications 

C323  (4/95) 

Mandated 

(Approved) 

CPC 

X/Open 

HKSSEHi 

C321  (4/95) 

Mandated 

(Approved) 

3.8.3.9.2  Alternative  specification.  Proprietary  software  is  available  for  MS-Windows  which 
provides  the  same  functionality;  "Day-Timer"  and  "Maximizer"  are  two  well-known  examples. 
Interoperability  between  such  proprietary  packages  is  virtually  nonexistent 

3.8.3.9J  Standard  deficiencies.  No  standard  deficiencies  are  known  at  this  time. 

3.5.3.9.4  Portability  caveats.  None 

3.8.3.9.5  Related  standards.  None 

3.8.3.9.6  Recommendations.  XCDE  is  recommended  for  GUI  environments.  XCS  defines  data 
structures  and  interfaces  for  developers  wishing  to  make  applications  "calendar-aware."  The 
XCDE  "drag  and  drop"  facility  allows  users  to  associate  documents  with  meetings  by  dropping 
them  on  the  calendar. 
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3.8.4  Real  time  extensions.  Real  time  extension  standards  provide  interfaces  with  a  collection  of 
services  designed  to  support  predictable  responses  to  asynchronous  events.  In  data  processing  or 
data  communications,  real  time  means  the  data  is  processed  the  moment  it  enters  a  computer,  as 
opposed  to  BATCH  processing  where  the  information  enters  the  system,  then  is  stored  and 
operated  on  at  a  later  time. 

3.8.4.1  Scheduling.  (This  BSA  appears  both  in  part  8  and  part  9.)  Scheduling  services  and 
interfaces  provide  different  scheduling  policies,  such  as  time-sharing,  priority-based,  and  user- 
defined.  Scheduling  services  initiate  and  terminate  jobs  (programs)  in  the  computer,  maintain  a 
list  of  jobs  to  be  run,  and  allocate  computer  resources  depending  on  priority.  Each  process  is 
controlled  by  an  associated  scheduling  policy  and  priority. 

Priority  and  preemptive  scheduling  standards  provide  interfaces  to  scheduling  services  allowing 
the  highest-priority  process  to  run  first  and  to  completion.  Preemptive  multitasking  shares 
processing  time  with  all  running  programs.  For  example,  background  programs  can  be  given 
recurrent  CPU  time  no  matter  how  heavy  the  foreground  load.  Priority  bumping  is  the  process 
during  a  link,  trunk,  or  facility  failure  where  lower  priority  user  access  to  network  services  is 
interrupted  to  offer  those  services  or  bandwidth  to  a  predesignated  higher  priority  user. 

3.8.4.1.1  Standards.  Table  3.8-30  presents  standards  for  scheduling. 


TABLE  3.8-30  Scheduling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  I : 
System  API  (Replaces  ISO  9945- 1 : 1990  end  incorporates 
IEEE  1003.1b.  1003.1c.  and  1003.10 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphici  Device  Interface, 
Volume  1  Microsoft  Win32  Programmer*’  Reference 
Manual,  1993.  Microtoft  Pre»* 

Win32  API* 

Mandated 

(Approved) 

NPC 

IEEE 

Portable  Operating  System  Interface  (POSDO  -  Part  l : 
System  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Infoimational  jj 
(Approved)  i 

NPC 

IEEE 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  [C  Language! 

1003. 1  i:  1995 

Informational  | 
(Approved)  H 

OPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  •  System 
Application  Program  Interface/  C  Language  (adopts 
ISO/IEC  9945-1 11990) 

R PS  PUB  151- 
2:1993 

Informational  | 
(Approved)  | 

m: 
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3.8.4.1.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 
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3X4.13  Standards  deficiencies.  The  POSIX.l  standard  is  not  suitable  for  real  time  applications, 
because  it  supports  only  time-sliced  time-sharing  scheduling  and  does  not  allow  scheduling  based 
on  the  priority  of  a  process. 

The  POS1X  “nice"  command  for  adjusting  process  priorities  is  not  suitable  for  real  time 
applications,  because  the  “nice"  function  is  merely  a  request  to  the  operating  system  to  favor  a 
particular  process  for  scheduling.  However,  in  traditional  Unix  and  POSIX.l,  the  effect  of  the 
"nice”  command  is  tempered  by  degrading  priorities  based  on  CPU  usage.  In  addition,  the  "nice" 
interface  specifies  an  adjustment  to  a  "nice"  value,  rather  than  setting  it  to  an  explicit  value.  Real 
time  applications  usually  want  to  set  priority  to.an  explicit  value.  Finally,  "nice()"  does  not  allow 
for  changing  the  priority  of  another  process. 

POSIX.l  scheduling  is  not  based  on  absolute  priorities.  A  process's  scheduling  priority  degrades 
as  it  runs.  POSIX.l  does  not  allow  a  system  operator  or  real  time  application  developer  to  tailor 
process  scheduling. 

POSIX.lb  does  not  address  the  priorities  of  "system"  processes.  If  system  processes  are  not 
running  in  low  priority  ranges,  conflicts  with  real  time  processes  could  result 

POSIX.  lb  does  not  address  the  interaction  between  priority  and  swapping  because  swapping  and 
virtual  memory  paging-related  issues  are  extremely  dependent  on  the  implementation  and  nearly 
impossible  to  standardize.  However,  the  POSIX. lb  scheduling  paradigm  fully  describes  the 
scheduling  behavior  of  runnable  processes,  including  the  requirement  for  the  working  set  to  be 
resident  in  memory. 

POSIX.  lb  does  not  address  the  temporary  lending  of  priority  from  one  process  to  another  by  the 
system  (e.g.,  for  the  purposes  of  affecting  the  freeing  of  resources). 

POSIX.  lb  does  not  define  the  effect  of  I/O  interruptions  and  other  system  processing  activities 
because  the  effect  of  I/O  interruptions  and  system  loading  is  intrinsically  nondeterministic. 

Influence  levels  (restrictions  on  a  process's  ability  to  affect  other  processes  beyond  a  certain  level) 
are  defined  by  the  implementation. 

POSIX.  lb  does  not  address  the  mechanisms  used  to  control  access  to  scheduling  facilities. 

POSIX.  1  b  does  not  address  whether  a  process'  handling  of  an  event  with  a  higher  priority  should 
have  its  priority  boosted.  This  may  be  addressed  later. 

POSIX.  1  b  provides  a  minimum  of  32  priority  levels.  While  this  number  conforms  to  the  currently 
accepted  scheduling  theory  requiring  at  least  32  priority  levels  for  predictable  responses  with 
acceptable  processor  utilization,  it  is  less  than  the  256  priority  levels  that  many  real  time  systems 
need. 
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3&4.1.4  Portability  caveats.  POSIX.  lb  supports  a  time-sharing  scheduling  policy,  a  real  time 
scheduling  policy,  and  a  user-defined  sch  eduling  policy,  but  does  not  define  the  default  scheduling 
policy.  This  could  cause  problems  in  porting  the  scheduling,  and  as  a  result,  could  cause 
problems  in  the  response  time  behavior  of  real  time  applications. 

POSIX.  lb  does  not  address  resource  preemption.  The  lack  of  resource  preemption 
standardization  could  affect  the  ability  to  port  real  time  applications  so  that  they  maintain  the 
same  behavior  be  veen  systems.  However,  this  does  not  affect  source  code  portability,  because 
resource  preemption  functions  lie  underneath  the  POSIX. lb  interface. 

The  POSIX.  1  b  priority-based  scheduling  functions  are  incompatible  with  the  System  V.4  S VID 
and  SVR4  real  time  extensions'  priority  scheduling.  The  System  V.4  "priocntlO"  interface  for 
priority  scheduling  violates  POSIX. lb  guidelines  since  it  uses  an  argument  to  define  the  system 
call  function.  This  increases  the  complexity  of  the  "priocntlO"  system  call  because  it  consolidates 
a  large  collection  of  related  but  logically  separate  functions  into  a  single  interface.  Aiso,  the 
"priocntlO"  interface  is  less  flexible  than  the  POSIX.lb  interface,  because  "priocntlO"  does  not 
permit  separate  disjointed  or  overlapping  priority  ranges  between  policies. 

The  specification  of  only  32  priority  !rv  Is  could  reduce  the  behavior  of  some  applications  that 
depend  on  multiple  priority  levels  to  have  reduced  portability  across  conforming  implementations. 

In r.  conforming  implementation,  the  priority  ranges  for  the  FIFO  and  Round  Robin  scheduling 
policies  (SCHED_FIFO  and  SCHED_RR)  defined  in  the  header  <sched.h>  must  be  a 'lowed  to 
overlap,  because  these  scheduling  policies  are  identical  except  for  the  time  into!  aiJ.  'jo-cause  the 
third  scheduli  g  policy  permitted  by  POSIX.lb  (SCHED_OTHER)  is  defined  by  the  user  or 
implementation,  any  interactions  among  SCHED_OTHER  and  SCHED_FIFO  or  SCHED_RR 
also  is  defined  by  the  implementation.  Therefore,  any  application  that  depends  on  this  interaction 
is  not  a  strictly  conforming  application,  and  may  not  be  portable  across  all  systems. 

3.5.4.1.5  Related  standards.  The  following  standard  is  related  to  priority  and  preemptive 
scheduling  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

3.8.4.1.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  :  /  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1: 1990,  IEEE  1003.1b:1993, 
IEEE  IOt: 1  c:  1 995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  Federal  Information  Processing  Standard  IPS)  151-2  should  also  be  consulted.  It 
adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996  version.  IEEE  1003. lb  standardized 
additional  functions  not  in  the  original  POSIX. 1.  FIPS  151-2  specifies  many  of  the 
implementation-defined  system  limits  and  chooses  among  incompatible  POSIX  options. 

Each  real  time  functionality  in  the  POSIX.  1  b  standard  is  an  option.  If  procurements  do  not  call 
out  the  POSIX.lb  Execution  Scheduling  option  explicitly,  vendors  may  provide  a  system 
conforming  with  POSIX.  lb  but  not  including  this  option. 
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Procurements  should  require  implementations  to  document  the  priority  ranges  in  which  system 
processes  run  to  check  that  conflicts  will  not  exist  between  system  processes  and  real  time 
processes. 

If  a  particular  default  scheduling  policy  is  desired,  a  procurement  should  either  specify  the  default 
explicitly  or  specify  the  ability  for  system  operators  to  define  one. 

System  processes  always  should  execute  in  low  priority  ranges  to  avoid  conflict  with  real  time 
processes. 

A  portable,  standardized  interface  for  locking  portions  of  a  process  in  memory  is  necessary  to 
ensure  that  paging  behavior  does  not  affect  the  scheduling  of  real  time  processes. 

An  organization-wide  standard  default  scheduling  policy  should  be  established.  Also,  applications 
should  make  no  assumptions  about  the  default  scheduling  policy. 

Although  the  POSIX.  lb  real  time  standard  allows  source  code  portable  applications  to  be  written, 
it  does  not  guarantee  that  two  such  applications  can  coexist  in  a  single  system.  To  minimize 
conflicts,  developers  should  adhere  to  certain  programming  guidelines  to  document  the  intent, 
rather  than  the  syntax,  of  the  standardization  issues. 
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3 .8.4.2  Kernel  preemption.  Kernel  preemption  provides  support  for  the  immediate  preemption 
of  running  operating  system  kernel  processes  to  dispatch  a  higher  priority  process  as  soon  as 
possible. 

3.8.4.2.I  Standards.  Table  3.8-31  presents  standards  for  kernel  preemption. 


TABLE  3.8-31  Kernel  preemption  standards 


1  Standard 
|  Type 

Sponsor 

Standard 

Standard 

Reference 

m 
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3JL4.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Proprietary  real  time  Unix  systems. 

b.  Proprietary  real  time  executives. 

c.  "Home-grown"  real  time  kernels. 

d.  OSF,  working  in  conjunction  with  the  Center  for  High  Performance  Computing,  to 
develop  a  real-time  Mach  microkernel. 

3JL4.2.3  Standards  deficiencies.  Preemption  of  processes,  particularly  kernel  processes  (kernel 
preemption),  is  necessary  for  many  critical  real  time  applications.  Kernel  preemption  is  a  function 
of  an  operating  system  implementation,  not  a  standardized  interface.  Basic  Unix  does  not  support 
kernel  preemption  at  all. 

3J1.4.2.4  Portability  caveats.  The  lack  of  a  standard  for  kernel  preemption  can  reduce  the 
portability  of  real  time  application  behavior  across  systems.  However,  it  should  not  reduce  real 
time  application  source  code  portability  because  the  functions  responsible  for  kernel  preemption 
are  underneath  the  real  time  operating  system  interface. 

Recently,  skinny  microkernels  have  been  discussed  as  the  future  of  real  time  operating  systems.  A 
real  time  microkernel  can  be  embedded  in  a  POSIX/Unix  system  for  general  real  time  use.  For 
critical  real  time  applications,  the  microkernel  can  be  used  as  a  stand-alone,  real  time  executive. 
Many  people  do  not  realize  that  the  stand-alone  microkernel  is  not  compatible  with  POSIX  or 
Unix.  The  source  code  of  applications  or  parts  of  applications  written  directly  to  the  microkernel 
are  not  portable  across  POSIX  or  Unix  systems. 

3.8.4.2.S  Related  standards.  The  following  standard  is  related  to  kernel  preemption  standards: 
a.  ISO/1EC  9945-1 : 1996:  POSIX  Part  I : System  Applicatin  Programming  Interface. 


April?,  1997 


3.8-66 


Version  3.1 


Information  Technology  Standards  Guidance 


Opening  Sanaa  Savicca 


3JU.2.6  Recommendations.  There  is  no  specific  standard  for  kernel  preemption,  but  kernel 
preemption  must  cooperate  with  IEEE  1003.  lb.  The  following  wording  is  recommended  for 
specifying  kernel  preemption  services: 

"Real  time  systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  provide  as 
full  as  possible  kernel  preemption,  as  opposed  to  preemption  via  preemption  points.  At  the  same 
time,  they  shall  conform  to  the  requirements,  services,  and  interfaces  specified  in  the 
IEEE  1003.1b  standard  for  all  features  and  functionality  specified  elsewhere  in  this  document" 
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3 .8.4.3  Semaphore  functions.  Semaphore  standards  provide  operating  system  synchronization. 
One  type  of  semaphore  is  a  message  sent  when  a  file  is  opened  to  prevent  other  users  from 
opening  the  same  file  at  the  same  time.  Its  purpose  is  to  preserve  the  integrity  of  data  (i.e.,  stop  it 
from  being  unknowingly  altered)  during  use.  Semaphores  can  be  implemented  as  follows: 

a.  Hardware  or  software  flags  used  to  indicate  the  status  of  some  activity. 

b.  Shared  space  for  interprocess  communications  (1PC)  controlled  by  "wake  up"  and 
"sleep"  commands.  The  source  process  fills  a  queue  and  goes  to  sleep  until  the 
destination  process  uses  the  data  and  tells  the  source  process  to  wake  up. 

3.8.4.3.1  Standards.  Table  3.8-32  presents  standards  for  semaphore  functions. 


TABLE  3.8-32  Semaphore  functions  standards 


Standard 

Type 


Sponsor 


Standard 

Reference 


Portable  Operating  System  Interface  (POSIX)  Part  1 : 

S’ 'stem  API  Replace*  ISO  9945-1 : 1990  and  incorporates 
IEEE  1003.  Ib,  1003.1c,  and  1003.lt) 


UNIX  Specification,  System  Interface  Definitions, 
Venion  2,  Issue  S 


A  Specification,  System  Interfaces  and  Headers, 
Venion  2,  Issue  5 


/•afro  Operating  System  Interface  (POSIX)  -  Part  1 : 
item  Application  Program  Interface  (API)  Amendment 
l:  Realtime  Extension  (C  language) 


POSIX  Part  1:  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  1C  Language] 


POSIX  Part  1 :  System  Application  Program  Interface 
(API)  Amendment  2:  Threads  Extension  (C  Language) 


Mandated 

(Approved) 


Emerging 

(Approved) 


Emerging 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


3.8.4.3.2  Alternative  specifications.  The  following  specifications  are  also  available: 


a.  Berkeley  Unix  Semaphores. 

b.  EventCounts  Services  and  Interfaces  (rather  than  semaphores). 
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c.  OSF:  OSF/1  Application  Environment  Specification,  1.1. 

3-8.4.3J  Standards  deficiencies.  POSIX.lb  has  no  concept  of  ownership  associated  with  a 
semaphore.  One  process  may  lock  a  semaphore,  and  a  second  process  may  unlock  it.  This  lack 
of  semaphore  ownership  has  many  advantages.  However,  it  also  means  that  it  is  not  possible  to 
implement  a  facility  at  the  operating  system  or  the  library  level,  whereby  the  system  could  track 
the  ownership  of  semaphores  for  error  recovery,  for  example. 

POSIX.lb  lacks  facilities  to  prevent  "priority  inversion,"  a  situation  occuring  when  a  low  priority 
process  locks  a  semaphore,  thus  delaying  a  high  priority  process,  then  gets  preempted  by  one  or 
more  medium  priority  processes.  This  can  result  in  unpredictable  response  time  for  high  priority 
processes.  This  problem  usually  is  fixed  by  using  a  priority  inheritance  protocol.  Such  a  protocol 
is  not  applicable  to  the  general  semaphore  used  in  POSIX.lb,  because  there  can  be  no  assurance 
that  the  process  unlocking  the  semaphore  is  the  same  one  that  locks  it.  Therefore,  the 
implementation  cannot  determine  who  should  inherit  the  higher  priority. 

The  POSIX.lb  group  does  not  address  a  "mutex"  facility  that  allows  the  process  that  locks  a 
semaphore  to  become  tire  owner  of  the  semaphore;  however,  such  an  extension  is  being  included 
in  the  POSIX.lc  Threads  standard. 

The  semaphores  specified  by  the  SVID,  XPG4,  OSF,  and  Berkeley  4.2/4.3  Unix  are  too  complex 
to  use  for  many  real  time  applications.  POSIX.  lb  specifies  only  semaphores  whose  persistence 
implies  that  a  semaphore  and  its  associated  state  remain  valid  until  the  last  reference  is  released. 
This  is  a  change  from  earlier  drafts  where  nonpersistent  semaphores  could  be  specified.  These 
would  be  unlocked  if  not  actively  referenced  by  a  process,  even  though  the  name  remains. 

The  sem_ifpost()  function  for  posting  to  a  binary  semaphore  has  been  removed  (although  it  is 
standard  practice  in  some  contexts),  because  no  convincing  rationale  was  found  for  keeping  it. 

3.8.4.3.4  Portability  caveats.  The  number  of  different,  incompatible,  nonportable  semaphore 
specifications  is  almost  equal  to  the  number  of  different  standards  groups  and  consortia  specifying 
semaphores. 

The  SVID,  XPG4,  OSF,  and  Berkeley  4.2/4.3  Unix  specify  and/or  provide  "resource" 
semaphores.  The  POSIX.lb  real  time  extensions  specify  the  simpler  "binary"  semaphores.  Binary 
and  resource  semaphores  are  not  compatible.  Furthermore,  the  resource  semaphores  specified  by 
the  SVID  and  X/Open  are  not  compatible  with  the  resource  semaphores  specified  by  OSF/1  and 
Berkeley  4.2/4.3  Unix. 

The  POSIX.lb  semaphore  mechanism  is  unlike  the  proposed  mutex  and  condition  variable  facility 
of  POSIX  lc.  Although  this  problem  has  been  addressed  through  a  substantial  rewrite  of 
semaphores  retaining  the  1003.1b  binary  semaphore  functionality  while  closely  matching  the 
1003.  lc  facilities,  portability  and  incompatibility  difficulties  still  may  be  present. 
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3.S.4.3.5  Related  standards.  The  following  standard  is  related  to  semaphore  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSDC. 

3-8.4.3.0  Recommendations.  If  the  application  in  question  is  a  critical  real  time  application, 
specify  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003.1b  binary  semaphores.  First,  the 
simpler  binary  semaphore  is  more  suited  to  many  critical  real  time  applications.  Second, 
developers  write  or  customize  their  own  semaphores  for  many  critical  real  time  applications,  and 
the  simpler  binary  semaphores  are  easier  to  learn  and  customize.  The  following  wording  is 
recommended  for  specifying  real  time  semaphores: 

"Real  time  systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  provide  as 
full  as  possible  kernel  preemption,  as  opposed  to  preemption  via  preemption  points,  and,  at  the 
same  time,  shall  conform  to  the  requirements,  services,  and  interfaces  specified  in  the  IEEE 
1003.1b  standard  for  all  of  the  features  and  functionality  specified  elsewhere  in  this  document" 

The  more  complex  resource  semaphores  of  System  V  Unix  can  be  built  on  top  of  the  POSlX.lb 
binary  semaphores. 

If  nonpersistent  semaphore  behavior  is  needed,  it  may  be  emulated  by  removing  the  semaphore 
from  the  name  space  so  that  upon  the  last  close  of  the  semaphore,  all  resources  associated  with  it 
will  be  released.  If  two  unrelated  processes  want  nonpersistent  behavior,  either  they  must 
synchronize  up  front  or  they  must  provide  for  cleanup  when  they  have  no  further  use  for  the 
semaphore.  Such  methods  of  achieving  nonpersistent  semaphore  behavior  are  complex  and  can 
cause  portability  of  behavior  problems. 

Correctly  written  conforming  implementations  should  not  rely  on  either  persistence  or  non¬ 
persistence,  because  persistence  and  system  reboot  are  terms  that  mean  different  things  to 
different  people. 

Currently,  semaphores  cannot  be  implemented  using  POSIX.  lc  "mutexes"  and  condition  variables 
because  these  are  not  usable  between  processes.  A  reasonably  efficient  implementation  based  on 
mutexes  and  condition  variables  would  not  be  safe  enough  for  the  signal  handler  invocations  to 
post  to  semaphores  used  outside  of  signal  context. 

Applications  using  POSlX.lb  semaphores  must  be  careful  of  their  robustness  because  no  facility 
exists  for  determining  whether  one  of  the  cooperating  processes  suddenly  has  become 
uncooperative. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX. 2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3 JJ.4.4  Memory  management  Memory  management  services  provide  ways  to  optimize, 
protect  end  control  memory.  These  services  include  shared  memory,  memory  locking  and 
memory  mapping. 

Shared  memory  is  the  portion  of  memory  accessible  to  multiple  processes.  When  two  or  more 
processes  share  some  memory,  that  memory  is  in  two  (or  more)  places  at  once.  It's  mapped  into 
the  address  spaces  of  all  processes  concerned.  If  one  process  writes  a  value  into  a  particular  byte 
of  shared  memory,  the  other  processes  see  it  almost  immediately  (depending  on  the  physical 
characteristics  of  the  underlying  hardware  memory  coherence  system).  Virtual  memory  combines 
physical  memory  and  a  swap  space,  which  is  the  disk  space  used  for  memory  overflow.  Use  of 
virtual  memory  allows  different  processes  to  appear  to  share  the  same  physical  page,  and  it  makes 
the  computer  appear  to  have  more  memory  than  it  actually  does. 

Process  memory  locking  standards  provide  services  via  an  interface  allowing  a  programmer  to 
lock  a  program,  or  part  of  a  program  or  process,  in  main  memory  instead  of  letting  it  be  moved  to 
a  disk. 

Memory  mapped  I/O  refers  to  the  ability  of  a  system  to  have  its  data  transferred  by  transferring 
pointers  to  areas  of  memory. 

3.8.4.4.1  Standards.  Table  3.8-33  presents  standards  for  memory  management 


TABLE  3.8-33  Memory  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/ffiC 

Portable  Operating  System  Interface  (PGSEX)  Part  1 : 
System  API  (Replaces  ISO  9945-1:1990  and  incorporates 
IEEE  1003.  lb,  1003.1c,  and  1003.lt) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmers'  Reference 
Manual,  1993,  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface  Definitions, 
Version  2,  Issue  5 

C605  (2/97) 

Emerging 

(Approved) 

cpc 

X/Open 

Single  UNIX  Specification,  System  Interfaces  and  Heelers, 
Version  2,  Issue  5 

C606  (2/97) 

Emerging 

(Approved) 

NPC 

IRRK 

Portable  Operating  System  Interface  (POSIX)  •  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  *  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  [C  Language] 

1003.  li:  1995 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

■  •>  -  ••  . . .  .  ..  -  :  A  .  ■  ■■ 

§,2s3 

3.S.4.4.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley:  Berkeley  Software  Distribution  (BSD)  Unix. 

b.  OSF:  OSF/1  (product  implementation). 

7 ,8.4.43  Standards  deficiencies.  The  SVID,  XPG4,  OSF/1,  and  Berkeley  Unix  consider  shared 
memory  a  basic,  general  purpose,  system  capability.  However,  shared  memory  is  not  specified  in 
the  POSIX.  1  kernel  interfaces,  and  requires  the  specification  of  POSIX.  1  b  real  time  extensions  for 
non-real  time  procurements. 

POSIX. lb  leaves  the  behavior  of  "read(),"  "writeO,"  and  "IseekQ"  on  shared  memory  unspecified. 
However,  implementations  using  file  mapping  can  use  these  functions. 

POSIX. lb  specifies  only  persistent  shared  memory  objects.  This  reduces  the  complexity  resulting 
from  specifying  nonpersistent  objects.  However,  for  processes  to  share  memory,  the  mechanism 
supporting  nonpersistent  shared  memory  objects  must  be  emulated  by  processes  sharing  memory, 
an  additional  complexity. 

The  memory  mapping  functions  in  POSIX.  1  include  the  main  memory  allocation  and  deallocation 
functions,  which  are  applicable  only  to  the  C  programming  language.  POSIX.  1  memory  mapping 
functions  cannot  map  pages  of  memory.  No  de  jure  or  de  facto  standard  Fortran  binding  for  the 
POSIX.  lb  memory  mapping  is  either  approved  or  in  progress. 

POSIX.  lb  memory  locking  does  not  support  "lock  stacking,"  which  makes  it  impractical  to  use 
locking  transparently  in  library  functions  or  opaque  modules.  POSIX. lb  supports  no  specific 
interface  for  preallocating  stack  space  and  locking  it  down  -  a  common  real  time  requirement  that 
prevents  page  faults  from  allowing  the  stack  to  grow  during  real  time  operation.  Many 
architectures  support  system-managed  stacks  that  grow  automatically  when  their  current  extent  is 
exceeded.  A  real  time  application  is  required  to  be  able  to  "preallocate"  sufficient  stack  space  and 
lock  it  down,  so  it  will  not  suffer  page  fault  to  allow  the  stack  to  grow  during  critical  real  time 
operation. 

3.S.4.4.4  Portability  caveats.  Although  shared  memory  functionality  is  supported  in  POSIX. lb, 
and  the  SVID,  the  process  is  not  quite  the  same.  The  shared  memory  facilities  are  the  same 
across  OSF,  X/Open,  and  the  SVID,  but  their  shared  memory  semantics  are  different  from 
POSIX.lb's.  The  POSIX. lb  standard  uses  pathnames,  while  System  V  Unix  uses  a  separate 
numeric  name  space  for  shared  memory, 
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POSIX.lb  specifies  interfaces  with  designated  separate  commands  to  perform  individual 
functions  (e.g.,  separate  commands  to  remove  a  shared  memory  segment,  change  the  shared 
memory  segment's  access  permissions,  and  change  its  owner).  In  contrast,  the  SVID  tends  to 
provide  a  single  command  for  shared  memory  (e.g.,  "shmcdO")  and  use  different  variables  and 
flags  to  indicate  different  functions. 

POSIX.  1  b's  process  memory  locking  requires  the  behavior  of  the  following  POSIX.  1  function 
calls  to  be  modified  to  support  the  memory  locking  mechanisms:  "exec(),"  "_ex it(),"  "fork()t"  and 
"sysconf()." 

Although  POSIX.lb  has  adopted  the  SVID's  "mlockallO"  and  "munlockallO"  interfaces  for 
process  memory  locking,  POSIX.  lb  has  extended  the  semantics  of  the  SVID  interfaces  to  ensure 
that  the  locked  pages  are  resident  when  the  locking  functions  return.  This  is  not  specified  in  the 
SVID.  Besides  "mlockallO,"  the  SVID  still  supports  the  System  V  original  "plockO"  command 
because  of  the  many  existing  applications  using  it  Applications  using  the  "plockO"  command  for 
memory  locking  are  not  compatible  with  POSIX.lb's  memory  locking. 

POSIX.lb  process  memory  locking  does  not  apply  to  POSIX.lb  shared  memory  regions,  and  the 
"MEMLOCK_FUTURE"  argument  to  "memlockall(>"  can  be  relied  upon  to  cause  new  shared 
memory  regions  to  be  locked  automatically. 

POSIX.lb  does  not  specify  the  SVID's  "memcntiO"  interfaces  for  memory  locking  control 
because  the  "memcntiO"  function  associates  a  multitude  of  functions  with  a  single  command,  a 
practice  POSIX.lb  shuns. 

The  POSIX.lb  interface  can  support  extensions,  such  as  mapping  objects  other  than  memory  or 
files,  more  easily  than  the  System  V  shared  memory  interface. 

Only  systems  with  hardware  supporting  protection  of  mapped  data  from  certain  classes  of  access 
can  support  the  POSIX.  1  b  Memory  Protection  option.  POSIX.  1  b  does  not  address  how 
implementations  that  choose  to  implement  memory  objects  directly  would  treat  them  with 
standard  utilities  such  as  "IS,"  on  the  grounds  that  utilities  are  not  within  the  charter  of  the 
POSIX.lb  standard. 

POSIX.lb  memory  mapped  I/O  cannot  be  mapped  literally  into  Fortran-77  in  a  portable  way 
because  POSIX.  lb  mem  y  mapped  I/O  implementations  return  a  process'  address  by  means  of  a 
pointer,  and  Fortran-77  does  not  support  pointer  data  types.  No  POSIX.  lb  language  binding  to 
Fortran-77  exists  to  map  the  shared  memory  constructs  in  a  standardized  manner. 

The  POSIX.lb  "mmapO"  and  "munmapO"  definitions  for  mapping  objects  into  process  address 
spaces,  and  subsequently  unmapping  them,  were  adopted  from  SVR4,  and  the  semantics  of  the 
POSIX.  lb  and  SVR4  system  calls  are  the  same.  The  OSF  Application  Environment  Specification 
(AES)  contains  a  nearly  identical  interface.  The  "mmapO"  and  "munmapO”  system  calls  are  part 
of  X/Open's  "Single  Unix  Specification"  (Spec,  1 170). 
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The  "mmap"  and  related  interfaces  in  the  OSF  Application  Environment  Specification  (AES)  are 
trial-use  interfaces  and,  therefore,  subject  to  change,  causing  potential  incompatibilities  among 
applications  written  to  the  trial-use  and  changed  interfaces.  The  history  of  "mmapO,"  which  is 
printed  in  Draft  12  of  the  POSIX.  lb  standard,  does  an  excellent  job  of  pointing  out  some  of  the 
portability  problems  that  users  may  run  into  with  different  specifications  and  implementations. 
Therefore,  this  history  is  reprinted  here, 

"Berkeley  invented  and  documented,  but  never  built,  mmap().  Sun  and  Berkeley  partially 
redesigned  the  mmapO  interface,  which  Sun  then  implemented.  SVR4  picked  up  the  Sun  mmap(). 
Meanwhile,  Berkeley  changed  their  minds  about  what  some  of  the  mmapO  parameters  should  be; 
they  changed  the  manual  page;  they  didn't  implement  this  either.  Now  enter  POSIX.4,  POSIX.4 
essentially  took  SVR4's  mmapO,  called  it  "shmmapO,"  and  added  the  new  "default  exact 
mapping"  feature  to  it.  They  did  this  by  overloading  the  address  NULL  to  do  something  different 
The  problem  with  this  is  that  zero  is  a  valid  address  on  many  machines.  This  effectively  precluded 
mapping  memory  at  address  zero.  Furthermore,  it  has  been  recognized  that  this  feature  added  no 
new  semantic  capabilities,  and  has  since  been  dropped  from  POSIX.4  entirely.  Meanwhile,  enter 
OSF.  The  OSF  originally  picked  up  the  SVID's  mmapO,  but  added  the  old  POSDC.4  NULL 
address  treatment  to  "follow  POSIX's  lead."  It  is  assumed  they  will  now  change  the  (trial  use) 
AES  mmapO  definition  to  match  the  rest  of  existing  practice.  (Note;  This  change  is  particularly 
important  for  program  loaders,  which  may  need  to  map  code  or  data  at  location  zero.)" 

Procurement  specifications  should  require  that  a  system  not  allow  default  exact  mapping  to  a 
"NULL"  address,  because  it  may  conflict  with  the  ability  to  map  memory  to  address  zero. 

3.5.4.4.5  Related  standards.  The  following  standards  are  related  to  memory  management  or 
memory  management  standards; 

a.  IEEE  P1003.1a:  POSIX  -  System  API  Extensions,  Language  Independent. 

b.  IEEE  1003.  le:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  R1003.5:1992:  ADA  Language  Binding  for  POSIX.  (Being  revised) 

d.  IEEE  1003.9:1992;  Standard  FORTRAN  Language  Bindings  to  POSIX. 

3.5.4.4.6  Recommendations.  1SO/IEC  9945-1: 1996  is  recommended.  It  incorporates  IEEE 
1003.1b  which  standardizes  additional  functions  not  in  the  1990  version  of  9945-1. 

The  following  wording  is  recommended  for  use  in  specifying  shared  memory  services: 

"Systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  provide  shared 
memory  capabilities  conforming  to  the  requirements,  services,  and  interfaces  specified  in  the  IEEE 
1003.1b  standard  which  is  incorporated  in  ISO  9945-1:1996,  for  all  the  features  and  functionality 
specified  elsewhere  in  this  document." 

Most  of  the  System  V  shared  memory  functionality  can  be  emulated  on  top  of  the  POSIX.  1  b 
interface.  An  example  of  how  to  do  this  is  given  in  draft  12  of  the  PI 003. lb  standard. 
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Pointer  problems  also  exist  with  shared  memory  in  the  SVID,  S  VR4,  and  XPG4.  In  these 
systems,  shared  memory  control  operations  require  the  use  of  a  pointer  to  the  shared  memory 
address  space.  This  pointer  operation  must  be  mapped  into  the  non-pointer  oriented  Fortran-77, 
and  no  portable  mapping  exists. 

When  a  mapping  is  established,  an  implementation  may  need  to  map  more  than  is  requested  into 
the  process'  address  space  because  of  hardware  requirements.  However,  an  application  cannot 
and  should  not  count  on  this  behavior.  Implementations  not  using  a  paged  architecture  simply 
may  allocate  a  common  memory  region  and  return  its  address.  Such  implementations  probably 
will  not  allocate  any  more  than  is  necessary. 

To  use  POSIX.lb  memory  mapped  I/O  with  Fortran-77,  choose  one  of  the  following  alternatives. 
The  first  is  to  use  the  Fortran-77  binding  in  P1003.9.  The  second  is  to  move  to  Fortran-90, 
which  does  support  pointer  data  types,  thereby  making  it  easier  to  map  POSIX.  lb  shared  memory 
constructs  to  Fortran.  The  third  alternative,  particularly  important  for  Fortran-77  legacy  systems 
in  the  absence  of  a  standardized  binding  mapping  the  shared  memory  constructs,  is  to  make  public 
the  name  of  a  COMMON,  and  then  bind  the  name  of  the  COMMON  (make  it  equivalent)  to  a 
locally  defined  COMMON  area.  Such  implementations  probably  will  have  to  place  restrictions  on 
the  size  and  alignment  of  such  structures,  or  will  have  to  map  a  suitable  region  of  the  process' 
address  space  into  the  memory  object,  and  thus  into  other  processes. 

The  following  wording  is  recommended  for  specifying  real  time  process  memory  locking: 

"Real  time  systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  provide 
memory  locking  capabilities  conforming  to  the  requirements,  services,  and  interfaces  specified  in 
the  IEEE  1003.1b  standard  which  is  incorporated  in  ISO  9945-1:1996." 

The  older  "plockO"  function  for  process  memory  locking  can  be  implemented  on  top  of  the 
optional  address  range  locking,  provided  the  implementation  has  the  means  to  locate  the  address 
space  ranges  corresponding  to  "text,"  "data,"  and  "stack"  segments.  The  plock()  interface  in  not 
specified  by  XPG4  or  the  Single  Unix  Specification. 

Although  memory  mapped  I/O  is  a  standard  part  of  the  SVID  and  OSF/1,  it  is  an  option  in  the 
recommended  POSIX.  1  standard.  If  procurements  do  not  specify  the  IEEE  P1003.1b  Standard's 
Memory  Mapped  Files  option,  vendors  may  provide  a  POSIX.lb  conformant  system  not  including 
this  option.  In  a  procurement  specification,  require  that  a  system  not  allow  default  exact  mapping 
to  a  "NULL"  address,  because  it  may  conflict  with  the  ability  to  map  memory  to  address  zero. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.4.5  Asynchronous  I/O.  Asynchronous  I/O  standards  provide  the  ability  to  overlap  currently 
executing  processes  and  I/O  operations  initiated  by  the  application. 


3.8.4.5.1  Standards.  Table  3.8-34  presents  standards  for  asynchronous  I/O. 


TABLE  3.8-34  Asynchronous  I/O  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Portable  Operating  Syrtem  lnterf ace  (POSIX)  Part  1: 
Syitem  API  (Replace*  ISO  9945*  1 : 1990  and  incorporate! 
IEEE  1003.1b.  1003.1c.  and  1003.  li) 

9945-1:1996 

Mandated 

(Approved) 

NPC 

IEEE 

Portable  Operating  Syitem  Interface  (POSIX)  •  Part  1 : 
Syitem  Application  Program  Interface  (API)  Amendment 

1;  Realtime  Extern  ion  (C  Unwaae) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

rFFK 

POSIX  Part  1 :  Syitem  Application  Program  Interface 
(API)  •  Amend:  Technical  Corrigenda  to  Real  Time 
B»l«uioolCUnfu««| 

1003.11:1995 

Informational 

(Approved) 

11 

lii&il 

3.S.4.5.2  Alternative  specifications.  For  true  asynchronous  I/O,  only  proprietary  products  will 
suffice.  For  nonblocking  I/O:  System  V's  "pollf)  and  terminal  driver  settings,  Berkeley  4.3  Unix's 
"selectO"  and  "[SIGIO]"  features  can  be  used.  Both  Berkeley's  "selectO"  and  System  V's  "poll()" 
are  required  by  X/Open's  Single  Unix  Specification  (Spec.  1 170), 

3.8.4.S  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.4.5.4  Portability  caveats.  Mixing  existing  nonblocking  I/O  with  the  newer  asynchronous  I/O 
can  cause  portability  problems. 

The  unwise  use  of  signals  with  the  POSIX.lb  asynchronous  I/O  interfaces  can  cause  a  problem 
whose  cause  is  difficult  to  determine,  because  the  blocking  function  can  return  with  a  particular 
symbolic  error  number  when  another  error  caused  the  problem. 

3.8.4.5.5  Related  standards.  The  following  standards  are  related  to  asynchronous  I/O  standards: 

a.  IEEE  P1003.  le:  Security  Interface  Standards  for  POSIX. 

b.  IEEE  1003.10:1995:  POSIX  -  Supercomputing  Applications. 

3.8.4.5.6  Recommendations.  The  following  wording  is  recommended  for  specifying  real  time 
asynchronous  I/O: 

"Real  time  systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  provide 
asynchronous  I/O  capabilities  conforming  to  the  requirements,  services,  and  interfaces  specified  in 
the  IEEE  1003.1b  standard  which  is  incorporated  in  1SO/IEC  9945-1:1996." 
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System  V's  shared  memory  and  semaphores  may  be  used,  albeit  at  high  cost,  to  perform 
asynchronous  I/O,  Since  the  POSIX.  lb  asynchronous  I/O  supplements  but  does  not  replace  the 
functions  of  the  existing  nonblocking  interfaces  available  on  most  Unix  systems,  building  the  older 
Unix  functions  on  the  new  POSIX  asynchronous  I/O  function  is  not  easy. 
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3 .8.4.6  Asynchronous  event  notification.  Asynchronous  event  notification  is  a  facility  that 
notifies  a  process  of  different  types  of  ever' s  concerning  it  in  a  consistent  and  reliable  manner. 


3.8.4.6.1  Standards.  Table  3.8-35  presents  standards  for  asynchronous  event  notification. 


TABLE  3.8-35  Asynchronous  event  notification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

IPC 

ISf 

Portable  Operating  Sy  item  Interface  (POSIX)  Pvt  1 : 
System  API  (Replace!  ISO  9945- 1:1990  and  incorporate* 
IEEE  1003.1b.  1003.1c,  and  I003.1i) 

9945-1:1996 

Mandated 

(Approved) 

NPC 

TFPF 

1003.1b:1993 

Informational 

(Approved) 

NPC 

rFRF. 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Conigeoda  to  Real  Time 
Extension  [C  Language  1 

1003. 1  i:  1995 

inform  ationaJ 
(Approved) 

HR 

» 

1 

Dnimyte 

(E*am 

'  M ' 

mssM 

3.8.4.6.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.4.6J  Standards  deficiencies.  The  ISO/IEC  9945-1:1996  standard  now  includes  POSIX.lb 
real  time  signals  and  supports  many  functions  not  in  the  1 990  version  of  9945- 1 .  These  include 
reliable  delivery  of  event  notification,  prioritized  delivery  of  event  notifications,  and  the 
differentiation  among  multiple  signals  of  the  same  type. 

Many  people  consider  the  POSIX.lb  asynchronous  event  notification  to  be  overly  detailed  and 
complex  because  it  is  implemented  as  part  of  the  signals  mechanism.  Using  a  single  signals 
mechanism  to  handle  ordinary  signals  and  asynchronous  event  notification  requires  system 
developers  to  deal  with  a  large  amount  of  complex  signals  flags,  variables,  and  other  details. 
Having  one  interface  handle  multiple  functionalities  is  contrary  to  POS1X.  lb's  usual  approach  of 
defining  a  separate,  clearly-understood  interface  for  each  functionality  (e.g.,  one  interface  for 
signals  and  another  one  for  asynchronous  event  notification).  In  *his  case  opponents  of  the 
separate  interface  for  each  functionality  approach  argued  that  the  separate  interface  approach 
would  require  the  implementation  and  maintenance  of  interfaces  with  different  names. 

3.8.4.6.4  Portability  caveats.  If  POSIX.  1  b  real  time  signals  providing  reliable  asynchronous 
event  notification  is  integrated  with  the  more  common  unreliable  asynchronous  event  notification, 
system  behavior  cannot  be  guaranteed  to  be  portable. 

3.8.4.6.5  Related  standards.  The  following  standards  are  related  to  asynchronous  event 
notification  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 
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b.  IEEE  P1003.  lg:  Protocol  Independent  Interfaces. 

c.  OSF:  Distributed  Computing  Environment  (DCE). 

3.8.4.6.S  Recommendations.  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003.1b  is 
recommended.  Because  reliable  asynchronous  event  notification  is  such  an  important  capability 
for  real  time,  networking,  distributed  management,  and  transaction  processing,  procurements 
should  specify  the  POSIX.  lb  Real  Time  Signals  option;  otherwise,  vendors  probably  will  not 
provide  it 
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3A4.7  Synchronized  I/O.  Synchronized  I/O  (also  known  as  synchronous  I/O)  refers  to  the 
ability  of  a  system  to  have  transferred  its  data  to  nonvolatile  media  by  the  time  the  system  signals 
completion. 

3.8.4.7.I  Standards.  Table  3.8-36  presents  standards  for  synchronized  I/O. 


TABLE  3.8-36  Synchronized  I/O  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

in 

IPC 

ISO/TEC 

Portable  Operating  Syrtem  Interface  (POSIX)  Part  1 : 
Syilem  API  (Replace*  ISO  9945-1:1990  and  incorporate* 
IEEE  1003.1b.  1003.1c.  and  1003.10 

9945-1:1996 

Mandated 

(Approved) 

CPC 

X/Optrt 

Single  UNIX  Specification,  Syilem  Interface  Defaition*, 
Venion  2,  I**ue  5 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Op« 

Single  UNIX  Specification,  Syatem  Interface*  and  Header*. 
Version2,Iuue5 

C606  (2/97) 

Emerging 

(Approved) 

NPC 

IFPF 

Portable  Operating  Syilem  Interface  (POSIX)  -  Part  1: 
Syrtem  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Exteruion  (C  language) 

1003. lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  Syrtem  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extenaton  1C  Lantuacel 

1003.1i:1995 

Informational 

(Approved) 

wc 

■ 

H 

juju 

MW 

11131 

in 

BlB 

sin 

llllii 

3.8.4.7.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.2/4.3  Unix. 

b.  OSF:  OSF/1  Application  Environment  Specification  (AES)  1.1. 

3.8.4.7.3  Standards  deficiencies.  Although  the  POSIX.lb  "fsyncO"  function  has  been  adapted 
from  the  emerging  P1003.1a  standard,  the  POSIX.lb  specifiers  and  many  balloters  consider  the 
loosely  defined  POSIX.la  "fsyncO"  function  to  be  unacceptable  for  real  time  applications. 

3.R.4.7.4  Portability  caveats.  The  POSIX.lb  Synchronized  I/O  interface  is  similar  to  but  not 
exactly  like  the  one  described  in  the  Single  Unix  Specification  (Spec  1 170).  Berkeley  Unix 
systems  include  an  "fsyncO"  operation,  which  causes  synchronization  for  file  data  and  file 
attributes.  The  Berkeley  Unix  "fsyncO"  operation  has  been  incorporated  into  Spec  1 170;  thus 
both  the  System  V  and  Berkeley  Unix  styles  of  synchronous  I/O  are  availa,  :.  The  POSIX.  1  b 
Synchronized  I/O  interface  supports  two  levels  of  integrity  for  output  operations,  using  an 
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"0_SYNC"  and  an  "O.DSYNC"  flag.  The  POSIX.lb  "0_SYNC"  flag  is  essentially  tire  same  as 
the  "0_SYNC"  flag  described  in  the  Spec  1 170,  so  the  "0_SYNC"  flag  of  Spec  1 170  and  SVR4's 
"open()"  system  call  maps  directly  onto  the  POSIX.  lb  "0_SYNC"  flag.  Subsequent  output 
operations  of  "writeO"  will  behave  identically  in  System  V  and  POSIX.lb.  The  POSIX.lb  also 
has  an  "0_DSYNC"  flag,  which  specifies  a  less  stringent  form  of  integrity. 

The  SVID  does  not  impose  synchronized  I/O  on  input  operations.  The  POSIX.lb  Synchronized 
I/O  facility  extends  the  SVID's  facility  to  include  input  operations. 

POSIX.  la  (the  POSIX.  I  revision)  has  defined  an  "fsyncO"  function  abstractly  to  force  a  physical 
write  of  data  from  the  buffer  cache  and  synchronize  a  file's  state.  The  POSIX.lb  "fsyncO" 
function  is  more  specifically  and  rigorously  defined  to  meet  real  time  application  requirements. 

The  behavior  of  the  more  rigorous  POSIX.lb  "fsyncO  function  cannot  be  counted  on  to  be 
portable  to  the  less  rigorous  POSIX.  la  "fsyncO"  function. 

Not  all  file  systems  may  support  or  need  to  support  synchronized  VO.  Consequently,  when 
synchronized  I/O  is  specified  on  the  "open()"  or  "fcntlO"  functions,  the  function  may  fail  due  to 
the  fact  that  the  file  system  cannot  support  synchronized  I/O  for  the  specified  file. 

The  operating  system  cannot  protect  users  from  themselves  if  they  bypass  the  operating  system's 
protection  mechanism  and  use  raw  I/O  (directly  address  the  I/O  device).  Although  users  may 
provide  their  own  mechanisms  for  ensuring  data  and  file  integrity  if  they  use  raw  I/O,  neither  the 
protection  mechanisms  nor  the  raw  I/O  can  be  counted  on  to  be  portable  to  any  other  platform. 

3.8.4.7.5  Related  standards.  The  following  standard  is  related  to  synchronized  I/O  standards: 
a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

3.5.4.7.6  Recommendations.  ISO/IEC  9945- 1 : 1996  which  incorporates  IEEE  1003.  lb  is 
recommended.  Procurements  involving  programs  requiring  a  file  to  be  in  a  known  state,  for 
example,  procurements  for  transaction  facilities,  should  use  the  more  rigorous  POSIX.lb 
"fsyncO"  functions  to  ensure  that  all  modifications  to  a  file  or  files  caused  by  a  transaction  are 
recorded. 

If  the  less  rigorous  POSIX.  la  synchronized  I/O  facility  is  used,  look  to  the  conformance 
document  to  specify  what  behavior  can  be  expected  from  the  system.  If  procurements  do  not 
specify  the  POSIX.lb  Synchronized  I/O  option,  vendors  probably  will  provide  either  a  different 
and  nonportable  synchronized  (synchronous)  I/O  facility,  or  they  may  provide  a  POSIX.  1  b 
conformant  system  not  including  this  option. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX. 2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3X4.8  Real  time  file  system.  A  teal  time  file  system  is  a  high-performance  file  system  (e.g., 
contiguous  I/O  or  preallocated  I/O)  that  optimizes  data  storage  on  a  disk  to  minimize  the  disk 
access  time  when  retrieving  or  writing  data  on  the  disk.  Real  time  files  refer  to  the  ability  to 
specify  various  characteristics  regarding  how  normal  file  requests,  such  as  "read()"  and  "writeO," 
are  handled.  File  management  functions  include  create,  get  and  set  attributes,  get  cache  and 
buffer  capabilities,  and  allocate  and  release  data  buffers.  Real  time  files  are  associated  most 
commonly  with  contiguous  files  and  preallocated  files  minimizing  disk  access  time  when  reading 
or  writing  data  on  a  disk. 

3.8.4.8.1  Standards.  Table  3.8-37  presents  standards  for  real  time  file  systems. 


TABLE  3.8-37  Real  time  file  system  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  Syrian  Interface  (POSIX)  Part  1 : 
System  API  (Replace*  ISO  9945- 1 : 1990  and  incorporates 
IEEE  1003.1b.  1003.1c.  and  1003.10 

9945-1:1996 

Mandated 

(Approved) 

NPC 

fFFF 

Portable  Operating  System  Interface  (POSIX)  •  Part  I: 
System  Application  Proglim  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.1b:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  System  Application  Program  Interface 
(APT)  •  Amend:  Technical  Corrigenda  to  Real  Tune 
Extension  |C  Language] 

1003.  li:  1995 

Informational 

(Approved) 

rite  ' 

rukuu 

.  iSpc  . 

Niirr 

;:>V'  :.;x  ::  : 

i 

1 

3.8.4.8.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.4.8.3  Standards  deficiencies.  Data  are  not  guaranteed  to  be  delivered  to  the  underlying 
storage  media.  This  issue  should  have  been  discussed  in  Section  6.6  of  the  POSlX.lb  standard. 

POSIX.  lb  lacks  an  interface  that  allows  the  specification  of  bounded  performance.  POSIX.  1  b 
does  not  address  files  of  a  fixed  size  whose  contents  are  written  in  a  circular  fashion.  For 
example,  after  reaching  the  file's  size  limit,  subsequent  "writeO"  functions  would  overwrite  the 
beginning  of  the  file.  Such  a  capability  is  needed  primarily  for  logging  types  of  operations. 

POSlX.lb  lacks  a  specification  for  a  real  time  file  system,  such  as  contiguous  files  or  preallocated 
files,  which  are  needed  for  most  real  time  applications.  A  generic  real  time  file  specification  was 
included  it.  Draft  12  of  the  standard,  but  was  dropped  subsequently  due  to  controversy.  The 
group  is  working  on  real  time  files  for  the  POSlX.lb  revision. 

3.8.4.8.4  Portability  caveats.  Real  time  files  are  associated  most  commonly  with  contiguous  files 
and  preallocated  files  that  minimize  disk  access  time  when  reading  and  writing  data  on  a  disk. 
POSlX.lb  supports  attributes  for  contiguous  files,  preallocated  files,  direct  I/O,  cache  usage. 
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sequential  access,  aligned  transfers,  and  the  transfer  granularity.  Thus,  it  is  possible  to  have  two 
applications  compliant  with  POSIX.lb  with  incompatible  file  systems. 

The  requirements  for  real  time  file  usage  differed  in  the  areas  of  performance,  guaranteed  access 
to  resources,  and  guaranteed  delivery  of  data  to  a  nonvolatile  media  (not  memory).  These 
differences  influence  the  underlying  behavior  of  existing  interfaces.  Application  developers 
typically  employ  "tricks"  to  achieve  a  higher  level  of  performance  than  a  system  delivers  through 
the  normal  interface.  This  behavior  is  not  portable. 

One  of  the  areas  of  common  practice  with  the  greatest  variation  between  vendors  and  the  greatest 
resulting  incompatibility  is  the  persistence  of  file  attributes.  The  POSIX.  lb  standard  does  not 
alleviate  this  problem.  POSIX.  lb  requires  persistence  of  file  attributes  on  an  open  instance  basis. 
It  allows,  but  does  not  require,  more  persistent  implementations.  This  specification  does  not 
require  vendors  to  change  their  existing  systems  to  ensure  multivendor  compatibility. 

3.8.4.85  Related  standards.  The  following  standard  is  related  to  real  time  file  system  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

3.8.4.8.6  Recommendations.  If  capabilities  are  needed  to  address  fixed  size  files  written  in  a 
circular  fashion,  procurements  should  require  such  a  facility  to  be  implemented  as  library  functions 
using  functions  defined  in  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003. lb:  1993. 

If  procurements  do  not  specify  the  POSIX.  lb  Real-Time  Files  option,  the  recommended  standard, 
vendors  may  not  provide  it. 

Currently,  nothing  can  be  done  about  the  nonportability  of  performance  behavior  except  wait 
Because  the  POSIX.lb  specifiers  have  found  that  many  of  the  techniques  for  achieving  bounded 
levels  of  performance  are  common  to  many  implementations,  they  may  be  able  to  standardize  an 
interface  to  these  techniques. 

The  POS IX.  1  b  real  time  files  interface  uses  constant  nan  les  prefixed  with  ATC_  o:  ATB_,  and 
structure  members  prefixed  with  either  atc_  or  atb_.  Applications  should  avoid  using  identifiers 
of  this  form  to  preclude  name  conflicts  with  the  standard. 
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3X.4.9  Embedded  real  time.  Embedded  real  time  capabilities  provide  services  to  support 
embedded  real  time  applications  with  demanding  determinism  and  response  times.  An  embedded 
system  is  a  specialized  computer  used  to  control  a  device.  It  implies  software  that  integrates 
operating  system  and  application  functions. 

3.8.4.9.1  Standards.  Table  3.8-38  presents  standards  for  embedded  real  time. 


TABLE  3.8-38  Embedded  real  time  standards 


Standard 

Reference 

Standard 

Type 


Sponsor 


Standard 


3X4.9.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Proprietary  real  time  Unix  systems. 

b.  Proprietary  real  time  executives. 

c.  "Home  grown"  real  time  kernels. 

d.  Future:  Mach  microkernel  with  real  time  extensions. 

3.8.4.9J  Standards  deficiencies.  The  P1003. 13  standardized  profile  for  embedded  real  time 
applications  contains  too  many  high  overhead  POSIX.l  operations  (e.g.,  "fork()").  To  meet  the 
response  time  and  real  estate  requirements  of  embedded  real  time  applications,  the  P1003. 13 
Group  must  be  allowed  to  subset  POSIX.l  as  well  as  POSlX.lb.  However,  IEEE  and  ISO  rules 
do  not  allow  the  subsetting  of  a  base  standard.  Until  this  problem  is  solved,  a  practical  embedded 
real  time  POSSX  standard  cannot  exist. 

3.8.4.9.4  Portability  caveats.  If  software  companies  producing  real  time  operating  systems 
choose  different  functionalities  from  POSIX.  lb,  which  is  possible  because  each  functionality  is  an 
option,  portability  will  be  reduced. 

If  software  companies  producing  real  time  operating  systems  eliminate  different  high-overhead 
parts  of  POSIX.  1  to  meet  demanding  determinism  and  response  time  requirements  and  implement 
their  own  nonstandard  functions  to  replace  those  eliminated  from  POSIX.l,  their  POSlX.lb-  or 
POSIX. 13-conformant  operating  systems  will  be  different.  They  also  will  not  support  portable 
real  time  applications  across  other  vendors'  POSIX.  I  b-  or  POSIX.  13-conformant  systems. 

3.8.4.9.5  Related  standards.  The  following  standard  is  related  to  embedded  real  time  standards: 

a.  ISO/EEC  9945-1:1996;  POSIX  Part  1:  System  Application  Programming  Interface 
(Includes  Realtime  and  Threads  Amendments). 

b.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 
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3.8.4.9.6  Recommendations.  This  problem  needs  to  be  resolved.  Broad-based,  active 
participation  is  needed  to  force  a  decision  allowing  the  subsetting  of  a  base  standard  such  as 
POSDC.l  in  a  standardized  way  for  special  purposes. 
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3.8.4.10  Symbolic  real  time  debugging  aids.  Symbolic  real  time  debugging  aids  refer  to  a 
variety  of  real  time  specific  development  and  debugging  tools.  A  debugger  lets  you  stop  the 
program  at  a  specified  statement,  step  through  it  one  statement  at  a  time,  as  well  as  capture  and 
view  system  data  and  program  variables.  Modem  debuggers  link  source  and  object  code  so  that 
the  programmer  can  step  through  the  source  program  while  instructions  are  being  executed. 

3.8.4.10.1  Standards.  Table  3.8-39  presents  standards  for  symbolic  real  time  debugging  aids. 


Standard 

Type 

Sponsor 

pr  aa  j - - r-  ass - nu— h  — 

Standard 

1 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

MHM 

•*»  ■  J 

S5BB1BI 

(NAi 

3.8.4.10.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary 
(e.g.,  Harris  Computer,  Encore  Computer,  Concurrent  Computer,  Modcomp,  Wind  River 
Systems,  Silicon  Graphics,  Hewlett-Packard,  Sun  Microsystems,  Digital  Equipment  Corp.) 

3.8.4.10.3  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these 
services  are  not  part  of  any  formal  standard. 

3.8.4.10.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.8.4.10.5  Related  standards.  The  following  standards  are  related  to  symbolic  real  time 
debugging  aids: 

a.  NIST:  ISEE. 

b.  European  Computer  Manufacturers'  Association  (ECMA):  Portable  Common 
Tools  Environment  (PCTE). 

3.8.4.10.6  Recommendations.  No  standards  are  available  to  recommend. 
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3.8.4.11  Real  time  POSIX.lb  language  bindings.  These  standards  provide  a  language  interface 
to  the  POSIX.  1  b  real  time  standard. 

3.8.4.11.1  Standards.  Table  3.8-40  presents  standards  for  real  time  POSIX.lb  language  bindings. 


TABLE  3.8-40  Real  time  POSIX.lb  language  bindings  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  1: 
System  API  (Replace*  ISO  9945-1:1990  and  incorporate* 
IEEE  1003.1b.  1003.1c.  and  1003.  li) 

9945-1:1996 

Mandated 

(Approved) 

NPC 

1FFE 

Portable  Operating  System  Interface  (POSIX)  -  Put  1: 
System  Application  Program  Interface  (API)  Amcmtineat 

1 :  Realtime  Extension  (C  language) 

1003. lb: 1993 

Informational 

(Approved) 

NPC 

IFFF 

POSIX  Part  1 :  System  Application  Program  Interface 
(APT)  •  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  |C  Language] 

1003.1i:1995 

Informational 

(Approved) 

NPC 

[ffp 

POSIX  Ada  Language  Interface*  •  Part  1  -.Binding  for 
Realtime  Extensions 

1003.5b:  1996 
(former  1003.20) 

Informational 

(Approved) 

NPC 

ipPR 

Test  Method*  for  Measuring  Confomunce  to  POSIX  - 
System  Interfaces 

2003.1:1992 

Informational 

(Approved) 

sic 

1 

IBB 

BfcpaMI 

3.8.4.11.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.8.4. 11 J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.4.11.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.8.4.11.5  Related  standards.  There  are  no  related  standards. 

3.8.4.11.6  Recommendations.  ISO/IEC  9945-1:1996  which  incorporates  the  1003.1b  Realtime 
amendment  is  recommended. 
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3.8.5  Operating  system  security.  Security  services  present  standards,  guidelines,  models, 
frameworks,  and  other  documents  related  to  the  control  and  validation  of  information  in  an  open 
system.  Security  services  can  be  placed  at  various  layers  within  the  OSI  architecture.  The 
selection  of  the  appropriate  layers  to  place  security  services  within  a  system  depends  upon  the 
architecture  and  functional  requirements.Therefore,  the  system  architecture  and  functional 
requirements  will  influence  the  selection  of  standards  within  a  subservice  area.  The  selection  of 
subservice  areas  depends  on  the  selected  architecture  and  required  functionality.  DOD  policy 
covering  the  accreditation  process  must  be  adhered  to  to  obtain  approval  to  process  classified 
data. 


3.8.5.1  Operating  system  security.  (This  BSA  appears  in  both  part  8  and  part  10.)  Operating 
system  security  services  provide  basic  reference  monitor  services.  These  security  mechanisms 
control  the  flow  of  data  and  use  of  applications  to  ensure  the  system  security  policy  is  adhered  to. 


3.8.5.1.1  Standards.  Table  3.8-41  presents  standards  for  operating  system  security. 


Standard 

Type 

Sponsor 

GPC 

DOD 

GPC 

NIST 

IPC 

W  ISO 

GPC 

NIST 

IPC 

ISO/JEC 

TABLE  3.8-41  Operating  system  security  standards 


Standard 


PenonftJ  Identification 


SI  System «  Management,  Part  7:  Security  Alan 
Reporting  Function  (same  as  ITU-T  X.736) 


Standard 

Reference 

Status 

DoD 

(Lifecycle) 

DOD  5200-28- 
STD:  1985 

Maodaied 

(Approved) 

FIPS  PUB  112: 
1985 

Mandated 

(Approved) 

7498-2:1989 

Informational 

(Approved) 

FIPS  PUB  48:1977 

Informational 

(Approved) 

10164-7:1992 

Informational 

(Approved) 

we 

mtx 

Spam  it 

waft  - 

3.8.5.1.2  Alternate  specifications.  No  alternative  specifications  are  available. 


3.8.5.1.3  Standards  deficiencies.  General  operating  systems  for  personal  computers  are 
inherently  insecure  and  should  not  be  used  in  DOD  acquisitions  without  an  assurance  of  "add-on" 


April  7,  1997 


3.8-88 


Version  3.1 


Information  Technology  Standards  Guidance 


Operating  System  Services 


security  features  and  an  approved  security  risk  analysis  providing  at  least  a  C2  level  of  trust  per 
DOD  Directive  5200.28. 

The  DGSA  stresses  the  need  for  separation  mechanisms,  such  as  a  separation  kernel,  to  maintain 
strict  isolation,  that  is,  information  domains  must  be  completely  isolated  from  each  other.  The 
DGSA  concept  requires  that  information  transfers  between  domains  may  occur  if,  and  only  if,  a 
relationship  is  explicitly  defined  in  each  information  domain's  security  policy.  There  are  no  current 
or  emerging  standards  for  design  and  implementation  of  separation  kernels  nor  for  programming 
interfaces  for  separation  kernels. 

Due  to  its  age,  FIPS  48  does  not  include  information  on  modem  security  concepts. 

3.&5.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3JL5.1.5  Related  standards.  ISO/IEC  9945-1  as  profiled  by  FIPS  151-2  is  related  to  IEEE 
P1003.1e  and  IEEE  P1003.2c. 

The  following  Compartmented  Mode  Workstation  (CMW)  specifications  are  related  to  operating 
system  security: 

a.  DDS-2600-5502-87,  Security  Requirements  for  System  High  and  Compartmented 
Mode  Workstations 

b.  DDS-2600-6243-92,  Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

c.  DDS-2600-6216-91,  Compartmented  Mode  Workstation  (CMW)  Labeling: 
Encoding  Format 

d.  DDS-2600-6243-91,  Compartmented  Mode  Workstation  (CMW)  Labeling: 

Source  Code  and  User  Interface  Guidelines,  Revision  1 

3.8.5.1.6  Recommendations.  The  mandated  standards  are  recommended. 
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3X5.2  Electronic  hashing.  (This  BSA  appears  in  part  5,  part  7,  part  8,  and  part  10.)  Electronic 
hashing  services  compute  a  condensed  representation  of  a  message  or  a  data  file,  often  used  as  a 
measure  of  data  integrity  checking. 

3X5.2. 1  Standards.  Table  3.8-42  presents  standards  for  electronic  hashing. 


TABLE  3.8-42  Electronic  hashing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Secure  Hub  Standard  (SHS) 

FIPS  PUB  1  SC- 
li  1995 

Mandated 

(Approved) 

IPC 

ISO 

Hash  Function!.  Part  1 :  General  Model 

10111-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Hash  functions.  Put  2:  Huh  Ructions  Using  mi  N  Bit 
Block  Cipher  Algorithm 

10118-2:1994 

Informational 

(Approved) 

- - m . 

s/  s 

— 1 

Staw--) 

jig 

■■ 

S;.  . .  . :;;|s 

| 

|§g 

3X5.2.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3X5.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3X5.2.4  Portability  caveats.  Poi  (ability  problems  with  the  existing  specifications  are  unknown. 

3X5.25  Related  standards.  FIPS  PUB  180-1  supersedes  FIPS  PUB  180  and  is  required  for  use 
with  FIPS  PUB  186,  Digital  Signature  Standard. 

3X5.2.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  180-1 
specifies  SHA,  which  can  be  used  to  generate  a  message  digest.  SHA  is  required  for  use  with  the 
DSA  as  specifr.J  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  for  federal  applications. 
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3.8.55  Entity  authentication.  (This  BSA  appears  in  part  8,  part  9,  part  10,  and  part  11.)  Entity 
authentication  standards  address  data,  processes,  systems,  and  enterprises. 

3.855.1  Standards.  Table  3.8-43  presents  standards  for  entity  authentication. 


TABLE  3.8-43  Entity  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Traded  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Service* 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Computer  DaU  Authentication 

FIPS  PUB 
113:1985 

informational 

(Approved) 

GPC 

NIST 

Entity  Authentication  Using  Public  Key  Cryptography 

FIPS  PUB 
196:1996 

Emerging 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

Financial  Transactions  -  Retail  Banking  Security 
Requirements  for  Message  Authentication 

9807 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  -  Part  1:  General  Model 

9798-1:1991 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  •  Part  3:  Entity 
Authentication  Using  a  Public  Key  Algorithm 

9798-3:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Use  ox  Advanced  Authentication  Technology 
Alternatives 

FIPS  PUB 
190:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  2:  Mechanisms  Using 
Symmetric  Encipherment  Algorithms 

9798-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  4:  Mechanisms  Using  a 
Cryptographic  Check  Function 

9798-4:1995 

Informational 

(Approved) 

CPC 

X/Open 

Security  i-  efface  Specification:  Auditing  and 
Authentication 

S020:  1990 

Informational 

(Approved) 

wC 

^  TytohoSKiiil)  ti 

CCVmk*  U>T 

-  aztp 

181111 

SESl 

118111 

WSMM 

3.8.55.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.8.5.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.5.3.4  Portability  caveats.  OSF  DCE  Version  1.1's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 
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3A5  J.5  Related  standards.  The  following  standards  are  related  to  entity  authentication: 

a.  DOD  NCSC-TG-017,  Version  1,  September  1991,  Guide  to  Understanding 
Identification  and  Authentication  in  Trusted  Systems. 

b.  FIPS  PUB  196, 11  October  1996. 

FIPS  PUB  196  becomes  effective  6  April  1996.  It  is  based  on  ISO/IEC  9798- 
3:1993  and  specifies  two  challenge-response  protocols  by  which  entities  in  a 
computer  system  may  authenticate  their  identities  to  one  another.  FIPS  PUB  196 
is  for  use  in  public  key  based  challenge-response  and  authentication  systems  at  the 
application  layer  within  computer  and  digital  telecommunications  systems. 

3.8.S.3.6  Recommendations.  The  mandated  standards  are  recommended. 
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3Jj.5.4  Security  management.  (This  BSA  appears  in  part  7,  part  8,  part  9,  and  part  10.) 

Security  management  is  a  particular  instance  of  information  system  management  Security 
management  provides  supporting  services  that  contribute  to  the  protection  of  information  and 
resources  in  open  systems  in  accordance  with  information  domain  and  information  security 
policies.  The  basic  elements  that  must  be  managed  are  users,  security  policies,  information, 
information  processing  systems  that  support  one  or  more  security  policies,  and  the  security 
functions  that  support  the  security  mechanisms  (automated,  physical,  personnel,  or  procedural) 
used  to  implement  security  services.  For  each  of  these  elements,  the  managed  objects  that 
constitute  them  must  be  identified  and  maintained.  For  example,  users  must  be  known  and 
ter  ■  security  policies  must  be  represented  and  maintained  and  information  objects  must  be 
tiien-  and  maintained.  Security  policies,  security  services  and  security  mechanisms  are  the  first 
classes  of  managed  objects. 

3.&5.4.1  Standards.  Table  3.8-44  presents  standards  for  security  management 


TABLE  3.8-44  Security  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Tiurted  Computer  System*  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  Interpretation 

NCSC-TG-005, 
Version  1: 1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-021, 
Version  It  1991 

Mandated 

(Approved) 

CPC 

OSF 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
ref:  ISO  9594-4) 

X.518:  1993 

Informational 
(Approved)  | 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Services  (CMIS) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:I992 

Informational 

(Approved) 

IPC 

1SO/IEC 

Information  Technology  -  Open  Systems  Interconnection  - 
Common  Management  Information  Protocol  (CMIP)  -  Part 

I:  Specification  (Includes  amendment  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profile  Sets  1 1183-X.  12059- 
X.  and  12060-X.  includes  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  7:  Security  Alarm 
Reporting  Function  (same  as  ITU-T  X.736) 

10164-7:1992 

■mu 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  8:  Security  Audit  Trail 
Function  (same  as  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management.  Part  9:  Objects  and  Attributes 
for  Access  Control 

10164-9:1995 

Informational 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(same  as  CCITTX.800:199I) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

Informational 

(Approved) 
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Sponsor 


Standard 


K! 


Stanuard 
Refe  nee 


Status 


DoD 


Standard 

Type 


3.8.5.4.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.8.5.4.3  Standards  deficiencies.  Deficiencies  exist  in  standardization  of  security  policy  rule 
representation;  key  management,  including  generation,  distribution,  and  act  muting;  audit 
information  formats;  exchange  of  security  management  information;  and  remote  security 
management 

The  DGSA  principle  of  decision  and  enforcement  separation  requires  that  the  functions 
determining  how  to  enforce  a  security  policy  and  the  actual  enforcement  of  the  policy  be 
implemented  independently.  That  is,  the  enforcement  mechanisms  do  not  ne  .!  any  knowledge  of 
security  policy.  Standards  are  needed  for  object  class  definitions  for  classes  of  managed  objects 
and  for  methods  of  representing  security  policy. 

The  DGSA  calls  for  a  separation  mechanism,  such  as  sepiration  kernel,  tc  \  -Hate  all  calls  to 
security  critical  functions  to  ensure  that  strict  isolation  i:,  maintained.  Star  '.  ation  of  object 
class  definitions  for  management  of  critical  functions  used  within  the  sepal,  i  kernel  is  needed. 

The  present  ISO/1EC  10164-7  "Security  Alarm  Reporting  Function,"  and  10164-8,  "Security 
Audit  Trail  Function,"  standards  were  designed  with  network  security  in  mind.  Little  work  has 
been  done,  either  in  standards  groups  or  in  products,  on  how  to  use  these  standards  for  genera! 
system  management  (e.g.,  computer  systems  and  software.; 

FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  The  present  GNMP  specifications  require  ISO 
CMIS/CMIP  to  communicate  management  information  and  ISO  OS1  networking  protocols. 
Plans  are  for  the  GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with 
SNMP.  One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 
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No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 

The  IEEE  POSIX  Security  Working  Group  (formerly  P1003.6)  is  defining  security  extensions  to 
the  base  POSIX  interface  standard  (ISO  9945-1),  to  include  support  for  audit,  privilege, 
discretionaiy  and  mandatory  access  control,  and  information  labels.  These  have  been 
redesignated  IEEE  P1003.1e  and  IEEE  P1003.2c.  The  draft  standards  are  still  incomplete,  and 
the  specifications  may  change. 

The  POSIX/Unix  permission  bits  are  inadequate  for  fine-grained  control  over  exactly  which  users 
can  perform  specified  actions  to  particular  files. 

In  the  IETF,  efforts  to  develop  an  acceptable  security  standard  for  SNMPv2  have  been  on  hold 
since  September  1995  when  the  IETF  SNMP  Working  Group  failed  to  agree  on  the  proposals 
submitted.  Since  then,  two  sets  of  proposals  for  providing  SNMPv2  security  have  emerged.  The 
first  set  of  proposed  specifications,  the  User-based  Security  Model  (USEC),  also  referred  to  as 
SNMPv2u,  consists  of  two  documents:  RFC  1909,  "An  Administrative  Infrastructure  for 
SNMPv2"  and  RFC  1910,  "The  User-based  Security  Model  for  SNMPv2."  Both  RFCs  were 
issued  28  February  1996  and  are  classified  by  the  IETF  as  experimental  RFCs.  The  other 
proposal  is  known  as  SNMPv2*,  which  its  proponents  claim  is  heavily  based  on  USEC.  Neither 
USEC  nor  SNMPv2*  has  been  approved  for  a  standards  track  by  IETF. 

3.8.5.4.4  Portability  caveats.  The  structure  of  certain  traditional  UNIX  directories,  such  as  the 
familiar  "/tmp,"  "/usr/spool,"  and  "/usr/spool/mail"  directories  will  have  to  change  to 
accommodate  the  P1003.  le  and  P1003.2c  security  standards.  This  is  because  these  are 
directories  to  which  all  users  have  access  and  to  which  many  programs  write.  A  change  in  the 
way  programs  write  to  directories  has  the  potential  for  causing  software  portability  and  systems 
administrator  portability  problems. 

The  traditional  UNIX  permission  bits  that  have  been  carried  into  POSIX  are  inadequate  for 
defining  exactly  which  user  can  perform  specific  actions  on  specific  files.  Eliminating  the 
permission  bits  in  favor  of  Access  Control  Lists  could  make  the  secure  POSIX  systems 
incompatible  with  non-POSIX  compliant  systems  and  many  applications. 

OSF  DCE  Version  1.1  's  authentication  service  is  based  on  Kerberos  Version  5  (RFC  1510),  but  is 
not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds  testing  and  official  support  for  Kerberos 
Version  5. 

3.8.5.4.5  Related  standards.  ISO/IEC  9945-1  as  profiled  by  FIPS  PUB  151-2  is  related  to  IEEE 
P1003.1e  and  IEEE  P1003.2c. 

3.8.5.4.6  Recommendations.  The  mandated  standards  are  recommended. 

All  IEEE  P1003.1e  and  IEEE  P1003.2c  security  systems  should  incorporate  Access  Control  Lists 
as  an  optional  feature  in  addition  to  permission  bits  (not  "in  place  of"  permission  bits).  The 
incompatibilities  between  the  two  access  control  methods  (permission  bits  and  access  control 
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lists)  are  not  resolvable.  The  best  method  for  resolving  the  overall  problems  seem  to  be 
incorporation  Access  Control  Lists  as  an  optional  feature  on  top  of  permission  bits.  The 
permission  bits  would  represent  the  lowest  common  denominator  of  security,  showing  the 
maximum  amount  of  openness  possible  in  a  system.  Organizations  needing  only  the  lowest  level 
of  security  could  continue  to  use  tire  familiar  permission  bits  and  associated  "chmod"  command. 
Use  of  access  control  lists  will  require  a  change  in  security  policy  such  that  access  is  granted  if 
and  only  if  permission  is  granted  and  access  control  permits  it. 
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3.8.5 £  Operating  system  security  labeling.  (The  BSA  appears  in  part  8  and  part  10.) 
Operating  system  security  labeling  provides  a  security  labeling  service  in  support  of  end  system 
processing.  This  service  is  required  to  support  similar  or  shared  service  for  all  other  MSAs 
having  security  labels.  This  service  includes  any  translation  services  to  support  other  MSAs, 
achieve  host  system  independence,  or  protect  host  identity. 

3. 8.5. 5.1  Standards.  Table  3.8-45  presents  standards  for  operating  system  security  labeling. 


TABLE  35-45  Operating  system  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mu 

GPC 

DOD 

The  DOD  Tiurted  Computer  Syitemi  Evaluation  Criteria 

DOD  5200.28* 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS- 2600-6216- 
91 

Informational 

(Approved) 

GPC 

DOD 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compartmeoted  Mode  Woriutation  (CMW)  Evaluation 
Criteria 

DDS-260O-6243- 

92 

Informational 

(Approved) 

1 

H 

Hi 

IB 

i 

"S3? 

3.8.5.5.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.8.5.523  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.8.5.5.4  Portability  caveats.  Portability  rroblems  with  the  existing  standards  are  unknown. 

3.8.5.55  Related  standards.  DOD  5200. 1-R,  "Information  Security  Program  Regulation,"  June 
1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of  DOD 
information.  It  also  contains  DOD  policy  for  safeguarding  of  classified  information,  including 
accountability,  storage,  transmission,  and  destruction  of  the  information. 

3.8.5.S.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.8.6  Distributed  system  services.  Distributed  system  management  services  allow  systems 
and/or  enterprises  to  be  managed  from  any  node  in  the  enterprise.  In  some  cases  an  enterprise 
may  be  managed  as  a  single  unit,  but  management  tasks  can  be  performed  at  any  node.  In  other 
cases,  the  enterprise  may  be  split  into  multiple  domains,  each  having  its  own  management  system, 
but  the  different  management  systems  can  cooperate  with  each  other  and  exchange  and  use  each 
others'  management  information. 

3.8.6.!  Distributed  file  services.  (This  BSA  appears  in  part  8  and  part  1 1.)  Distributed  file 
services  (DFS)  is  a  distributed  client/server  application,  built  on  the  underlying  DCE  services.  It 
takes  full  advantage  of  the  lower-level  DCE  services  (such  as  RPC,  Security,  Threads,  and 
Directory)  and  the  distributed  computing  system.  DFS  provides  many  advantages  over 
centralized  systems.  It  provides  a  higher  availability  of  data  and  resources,  the  ability  to  share 
information  throughout  a  very  large  heterogeneous  system,  and  efficient  use  of  special  computing 
functionality.  Files  are  made  highly  available  through  replication,  or  caching,  making  it  possible  to 
access  a  copy  of  a  file  even  when  one  of  the  machines  on  which  a  file  is  stored  goes  down. 

Further,  users  are  able  to  work  with  unfamiliar  file  systems  without  having  to  know  the  unique 
commands  for  each  system. 

File  Transfer,  Access,  and  Management  (FTAM)  allows  for  the  effective  transfer,  access,  and 
management  of  different  file  types  on  remote  systems  by  creating  a  virtual  filestore  that  emulates 
the  file  services  offered  by  existing  file  service  systems. 

Remote  file  access  is  the  ability  to  access  and/or  change  a  file  type  or  content  at  a  location  other 
than  the  user's.  Remote  file  access  is  associated  with  distributed  processing/client-server 
architectures,  and  is  not  used  in  host-terminal  architectures. 

3.8.6.1.1  Standards.  Table  3.8-46  presents  standards  for  distributed  file  services. 


TABLE  3.8-46  Distributed  file  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Diitributed  Computing  Environment  (DCE)  Di*tributed 
File  Service  (DFS) 

DCE  1.1  DFS:  1994 

Mandated 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profile*  •  File  Tranifer,  Acce**  and 
Management  (FTAM)  -  Part*  1,4,  and  5  (Reference*  ISO 
8571  parti  1-5) 

mm 

Informational 

(Approved) 

CPC 

X/Open 

Protocol*  for  X/Open  PC  Interworking:  SMB.  Venion  2 

C209  (10/92) 

Informational 

(Approved) 

CPC 

X/Open 

Protocol*  for  X/Open  Interworking:  XNFS,  I**ue  4 

C218  (10/92) 

Informational 

(Approved) 

NPC 

IEEE 

OSI  API  -  File  Transfer,  Acce**,  and  Management  (FTAM) 
(C  Language) 

1238.1:1994 

Informational 

(Approved) 

WC  ' 

nm>%  r 

HYttfgfeg 

arif 

WS:  KumdtHe  S)*bo  Protocol  Spd&aioa 

RFC  1094:1989  ' 

Reoarmnetdetf) 
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3JL6.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.8.6.1.3  Standards  deficiencies.  Limited-Purpose  File  Transfer,  Access  and  Management 
(FTAM)  subsets  do  not  provide  file  access  capabilities.  Only  Full-Purpose  FTAM  subsets  provide 
such  capabilities.  Limited-Purpose  FTAM  subsets  cannot  interoperate  fully  with  Full-Purpose 
FTAM  subsets. 

IEEE  Transparent  File  Access  (TFA)  addresses  the  POSIX.l  refinements  needed  for  file  access, 
but  ignores  the  behavior  of  other  facilities  needed  for  file  access  between  nodes,  such  as  signals. 

The  Remote  File  System  (RFS)  is  associated  mostly  with  Unix-based  systems  rather  than  with 
heterogeneous  operating  systems  on  legacy  systems  as  the  Network  File  System  (NFS)  is. 

NFS  security  uses  the  not  very  secure  traditional  Unix  authentication  and  permissions.  Secure 
NFS  is  not  as  secure  as  it  could  be  because  it  ships  security  information  around  the  network. 

Although  the  Andrew  File  System  (AFS)  can  provide  good  networked  performance  because  it 
supports  client  caching,  this  requires  large  amounts  of  memory  and  disk  buffer  space,  as  well  as  a 
potentially  long  time  for  the  first  remotely  accessed  data  to  be  downloaded. 

3.8.6.1.4  Portability  caveats.  The  SVID  provides  facilities  for  getting  file  system  information 
about  a  mounted  file  system,  but  none  of  the  SVID  functions  ("statvfsO,"  "sftatvfsO,"  and 
"ustat()")  are  compatible  with  OSF/l's  comparable  functions  ("statfsO,"  "fstatfsO,"  and  "ustatO"), 
X/Open  specifies  enhancements  to  the  "popen"  and  “pclose"  system  calls. 

Because  TFA  does  not  go  beyond  the  POSIX.l  refinements  needed  for  file  access  and  address  the 
behavior  of  other  facilities  (e.g.,  signals)  between  nodes,  a  portability  risk  exists  in  using  TFA 
between  nodes.  The  TFA  has  two  specifications,  full  TFA  (which  provides  all  of  the  file  access 
services  specified  in  ISO  9945-1)  and  Subset  TFA  (which  defines  file  access  semantics,  which  are 
less  stringent  than  POSIX  requires.  Subset  TFA  also  is  designed  for  use  with  non-P1003. 1  file 
systems.  Consequently,  it  is  possible  to  have  two  systems  compliant  with  TFA,  which  are  not 
compatible  with  each  other,  and  which  also  may  not  be  totally  compatible  with  the  core  POSIX.  1 
file  system. 

The  AFS  is  a  superset  of  NFS,  and  IEEE  TFA  is  a  superset  of  AFS  and  NFS.  Thus,  a  little 
backward  compatibility  exists  between  TFA  and  AFS  and  between  AFS  and  NFS. 

Systems  using  different  FTAM  subsets  cannot  be  assured  of  portable  applications  or 
interoperability. 

3.8.6. 1.5  Related  standards.  The  following  standards  are  related  to  distributed  files  or 
distributed  file  standards: 

a.  ISO  9945- 1 : 1 996 :  (POS IX.  1 )  System  interfaces. 

b.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  -  API. 
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c.  IEEE  P13S1:  Association  Control  Service  Element  (ACSE)  API. 

d.  RFC  1057:  ONC  Remote  Procedure  Call  (RPC).  • 

e.  OSF:DCE  RPC. 

3.8.6.1.6  Recommendations.  The  OSF  Distributed  Computing  Environment  (DCE)  Distributed 
File  System  is  recommended  for  distributed  computing  environments  based  on  TCP/IP. 

MIL-STD-2045- 17508  is  recommended  for  legacy  systems  interoperability.  Parts  1,  3,  and  6  of 
the  MIL-STD  support  only  the  Limited-Purpose  FT AM  (simple  file  transfer  and  management) 
system.  This  system  does  not  provide  file  access  capabilities.  The  MIL-STD-2045- 17508,  parts 
4  and  5  support  Full-Purpose  FTAM  (Positional  file  transfer,  simple  file  access,  and 
management))  system.  Users  requiring  remote  file  access  capabilities,  basted  on  OS1  standards, 
should  use  parts  1, 4,  and  5  of  the  MIL-STD. 

An  API  to  FTAM  is  provided  by  IEEE  1238.1. 
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3 .8.6.2  Remote  login.  (This  BSA  appears  in  part  8  and  part  1 1.)  Remote  login  is  the  ability  of  a 
user  from  a  local  machin'  to  be  an  authorized  user  and  access  a  remote  machine. 

3.8.6.2.1  Standards.  Table  3.8-47  presents  standards  for  remote  login. 


TABLE  3.8-47  Remote  login  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

tPC 

IAB 

TELNET  Protocol 

Standard  8/RFC- 
854/RFC-855 

Mandated 

(Approved) 

IPC 

IAB 

Host  Requirements 

Standard  3/RFC- 
1122/RFC-1I23 

Mandated 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Protocol  Specification  for 
(he  Allocution  Control  Service  Element  (ACSE) 

8650:1988 

Informational 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profile  -  Internet  Remote  Login  Profile 
for  DoD  Communication!  (Reference*  IAB  Std  8  (RPC 
854  and  RFC  855  -  Telnet  Protocol:  1983)  and  IAB  Std  3 
(RFC  1 123  -  Requirement*  for  Internet  ho*U:1989)) 

MlL-STD-2045- 

17506:7/94 

Informational 

(Approved) 

IPC 

ISO 

Open  Syitem*  Interconnection- Virtual  Terminal  Basic 
C1a*s  Protocol 

9041:1990 

Informational 

(Approved) 

IPC 

ISO 

Open  Syitem*  Interconnection- Ba*ic  Connection  Oriented 
Presentation  Service  Definition 

8822:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Irtfercorwection -Connection-Oriented 
PmienUtiott  Protocol 

8823:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Sy  items  Inleroonnection-Connection-Oriented 
Session  Protocol 

8327:1987 

Informational 

(Approved) 

3.5.6.2.2  Alternative  specifications.  None 

3.8.6.2.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.8.6.2.4  Portability  caveats.  A  procurement  may  specify  Simple  Systems  or  Forms-Capable 
Systems  or  both.  However,  the  two  systems  cannot  interoperate,  and  applications  are  not 
portable  from  one  system  to  another.  Each  system  is  distinguished  by  the  VT  profile  it  supports: 
a  Simple  System  supports  the  TELNET  profile,  and  a  Forms-Capable  System  supports  the  Forms 
profile.  The  Basic  Class  VT  protocol  is  required  in  all  cases;  it  operates  independently  of  the 
Simple  or  Forms-Capable  Systems. 

3.8.6.2.5  Related  standards.  None 

3.8.6.2.6  Recommendations.  All  new  systems  and  systems  undergoing  major  upgrades  should 
use  the  Internet  Architecture  Board  (IAB)  STD  8  (RFC  854  and  855)  and  IAB  STD  3  (RFC 

1 123).  Those  persons  conducting  procurements  that  involve  IAB  standards  should  review  the 
latest  version  of  the  IAB  official  protocol  standards  list  to  ensure  that  the  appropriate  RFCs  are 
specified. 


April  7,  1997 


3.8-101 


Version  3.1 


Information  Technology  Standards  Ouidand 


Operating  System  Services 


The  OSI  Virtual  Terminal  (VT)  standard  is  recommended  for  legacy  systems  intercperability.  A 
clear  migration  path  to  page,  scroll,  graphics,  and  mixed  mode  virtual  terminal  profiles  that  are 
being  defined  by  the  OSE  Implementors'  Workshop  (OIW)/NIST  should  be  required.  Otherwise, 
systems  capable  of  employing  only  TELNET  and  Forms  will  not  interoperate  with  future  VT 
systems.  The  "rlogin"  facilities  are  delivered  with  Berkeley  BSD-based  UNIX  operating  systems. 
Those  facilities  are  not  in  the  System  V  Interface  Definition  (S VTD). 

Currently,  a  Simple  VT  and  a  Forms-Capable  VT  exist.  Few  vendors  have  implemented  a  simple 
version  of  VT.  Procurements  need  to  determine  if  Simple  or  Forms-Capable  VT  Systems  are 
sufficient  for  the  application.  No  tests  have  been  developed  for  VT  to  test  conformance.  Remote 
login  is  associated  with  distributed  processing/client-server  architectures.  It  is  not  used  in  host- 
terminal  architectures. 

No  standards  exist  for  VT  API.  A  procurement  for  a  VT  final  system  must  include  a  vendor's 
offering  of  virtual  terminal  API.  This  API  should  accommodate  as  many  VT  types  as  possible. 
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3.8.6 3  Remote  shell  execution.  Remote  shell  execution  services  are  facilities  to  execute  an 
operating  system  shell  remotely. 

3.8.6 .3.1  Standards.  Table  3.8-48  presents  standards  for  remote  shell  execution. 


TABLE  3.8-48  Remote  shell  execution  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPN-C 

Betkdey 

Berkeley  nh/nhl 

Berkeley  UnU- 
TCP/IP 

Informational 

(Approved) 

liiiigi 

sss 

3.8.6 .3.2  Alternative  specifications.  Alternatives  include  any  implementation  of  Berkeley  Unix 
with  the  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP)  and  OSF/1  's  "rsh"  and  "rshl" 
functions. 

3.8.6.3J  Standards  deficiencies.  IEEE  1003.2  does  not  include  "rsh/rshl." 

3.S.6.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3-8.6.3.S  Related  standards.  No  standards  are  related  to  remote  shell  execution  standards. 

3.8.6.3  6  Recommendations.  The  only  standards  available  are  consortia  and  de  facto 
specifications;  they  are  equally  attractive  options.  Selection  may  be  based  on  the  use  of  other 
specifications  from  the  same  source. 

The  "rsh/rshl"  is  one  of  the  "remote"  commands  (often  called  the  "r"  commands)  developed  for 
Berkeley  Unix  4.2.  The  "r"  commands  are  not  specified  by  any  consortia  specification  and  have 
been  removed  from  X/Open  products. 
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3 .8.6.4  Remote  procedure  call.  (This  BSA  appears  in  part  8  and  part  1 1.)  Remote  procedure 
call  (RPC)  is  a  communication  service  to  transfer  procedure  calls  to  a  remote  server  and  return 
results,  errors,  or  associated  call  backs  (ECMA  127).  The  RPC  extends  die  local  procedure  call 
to  a  distributed  environment.  In  a  RPC,  a  process  can  invoke  a  remote  procedure  as  if  it  were 
invoking  a  local  procedure.  SC21/WG6  proposes  to  address  RPC  using  Inter,  ce  Definition 
Notation  (IDN)  that  is  based  on  abstract  data  types  rather  than  on  a  union  of :  gramming 
language-specific  data  types. 

3.8.6.4.1  Standards.  Table  3.8-49  presents  standards  for  remote  procedure  call. 


TABLE  3.rf-49  Remote  procedure  call  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Remote 
Procedure  C*ll  (RPC) 

DCE  1.1  RPC:  1994 

Mandated 

(Approved) 

CPC 

X/Open 

X/Open  DCE:  Remote  Procedure  Cell 

C309  (8)94) 

Information*] 

(Approved) 

CPC 

IETF 

Open  Network  Computing  (SUN  ONC)  Remote  Procedure 
Oil  (RPC) 

RFC  1057:1988 

Informed  on*l 
(Approved) 

a 

USUI 

(g* 

MMI 

IBM 

IBIM 

3.8.6.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.8.6.4 3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  arc  unknown. 

3.5.6.4.4  Portability  caveats.  All  the  indicated  RPCs  are  unique.  They  do  not  interoperate. 
Systems  using  different  RPCs  are  not  interoperable,  nor  are  their  applications  portable  across 
different  RPCs.  No  RPC  conformance  tests  are  available. 

3.8.6.4.5  Related  standards.  The  following  standards  are  related  to  RPC: 

a.  Common  Language  Independent  Data  Types  (CLID)  (ISO  1 1404). 

b.  Common  Language  Independent  Procedure  Call  Mechanism  (CLIP  or  CLIPCM). 
SC22/WG1 1  has  recommended  that  there  should  be  a  cross  reference  between  the 
standards. 

c.  NIST  FIPS  146-1:1991:  Government  Open  Systems  Interconnection  Profile 
(GOSIP),  ISO  8822,  ISO  8823  (SIA-5.8)  Presentation  (Layer  6),  Session  (Layer 
5)  ISO  8327  (SIA-5.9). 
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d.  NIST  FIPS  146-2  POSIT:  May  1995. 

S.8.6.4.6  Recommendations.  The  Open  Software  Foundation  (OSF)  Distributed  Computing 
Environment  (DCE)  is  recommended.  A  migration  path  to  the  ISO  RPC  also  should  be  required 
as  soon  as  that  standard  is  in  final  form. 

The  IEEE  P1003.21  draft  standard  includes  interfaces  for  the  support  of  request/response 
services. 
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3JL.6J  Protocol-independent  transport  service.  This  defines  a  protocol-independent 
application  interface  to  enable  one  process  to  communicate  with  another  local  or  remote  process 
over  a  network. 

3. 8.6.5. 1  Standards.  Table  3.8-50  presents  standards  for  protocol-independent  transport  service. 


TABLE  3.8-50  Protocol-independent  transport  service  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Single  UNIX  Specification,  Networking  Service*,  Vernon 
2,iMiie5 

C523  (2/97) 

Emerging 

(Approved) 

■■a 

Sfe  j/h 

■ 

31 

llllllll 

MM! 

11K1I 

wbsM 

BliM 

ifelil 

3.8.6.5.2  Alternative  specifications.  The  following  specification  is  available: 

a.  SAE  ARD  50067  Draft:  Avionics  Operating  System  API  Requirements. 

3.8.6.5J  Standards  deficiencies.  The  IEEE  P1003.1g  draft  standard  is  an  API  for  proccss-to- 
process  communications,  utilizing  the  X/Open  Transport  Interface  (XTI)  or  the  Berkeley  Sockets 
interface.  Although  IEEE  P1003.1g  will  be  sufficient  for  many  application  domains,  the  standard 
does  not  address  many  of  the  functions  required  by  many  real-time  applications.  Among  these  are 
multicast  services,  heterogeneous  communication,  message  priorities,  typed  messages,  lightweight 
directory  services,  explicit  buffer  management,  asynchronous  interactions,  bounded  blocking,  and 
event  management,  all  of  which  are  addressed  in  the  IEEE  P1003.21  standard. 

3.8.6.5.4  Portability  caveats.  IEEE  P1003.1g  addresses  two  existing  interfaces:  the  X/Open 
Transport  Interface  (XTI)  and  the  Berkeley  Sockets  interface.  In  order  to  maintain  the  portability 
of  existing  applications  in  XTI  and  Sockets,  both  interfaces  are  required  to  be  supported  in  any 
conformant  implementation.  In  addition,  IEEE  P1003.  lg  is  limited  to  transport  protocols  that  are 
compatible  with  XTI  and  Sockets.  The  IEEE  P1003.21  draft  standard  includes  mappings  to 
additional  protocols,  including  XTP  and  SCI. 

3.8.6.5.5  Related  standards.  The  following  standards  are  related  to  protocol-independent  service 
standards: 


a.  ISO/IEC  9945-1:1996:  POSIX  Part  1  -  System  Application  Program  Interface 
(Includes  realtime  and  threads). 
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b.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  -  API. 

c.  IEEE  1 224.2: 1993:  Directory  Services  -  API. 

d.  IEEE  1238.1:1994:  OSI  Applications  Program  Interface  -  FTAM. 

e.  IEEE  1351:1994:  Association  Control  Service  Element  (ACSE)  and  Presentation 
Layer  Services  -  API. 

3JL6.5.6  Recommendations.  The  IEEE  P1003.  lg  draft  standard  is  composed  of  a  common 
language-independent  specification  with  two  C-language  bindings:  one  compatible  with  the 
X/Open  Transport  Interface  (XTI),  and  one  compatible  with  the  Berkeley  Sockets  interface.  The 
IEEE  P1003.5c  draft  standard  is  the  corresponding  Ada  language  binding  for  XTI  and  Sockets. 

Issue  5  of  the  Single  UNIX  Specification  Includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.8.7  System  management  services.  Centralized  system  management  services  refer  to  services 
that  allow  systems  and/or  enterprises  to  be  managed  from  a  single,  centralized  point  Distributed 
system  management  services  refer  to  services  that  allow  systems  and/or  enterprises  to  be  managed 
from  any  node  in  the  enterprise,  in  a  variety  of  ways.  In  some  cases  an  enterprise  may  be 
managed  as  a  single  unit  but  management  tasks  can  be  performed  at  any  node.  In  other  cases,  the 
enterprise  may  be  split  into  multiple  domains,  each  having  its  own  management  system,  but  the 
different  management  systems  can  cooperate  with  each  other  and  exchange  and  use  each  others' 
management  information. 

3.8.7.1  System  administration  and  management  APIs.  (This  BSA  appears  in  part  8  and  part 
9.)  Operating  system-based  system  administration  standards  provide  interfaces  to  traditional, 
centralized  operating  system  administration  services  and  utilities.  System  management  APIs  refer 
to  standardized  Application  Programming  Interfaces  that  can  be  used  by  system  and  network 
managers  and  application  developers  to  manage  a  system  or  network.  They  also  are  used  to 
develop  a  system  or  network  management  application,  without  having  to  resort  to  writing  third- 
generation  language  code  or  UNIX/POSIX  shell  scripts  to  perform  the  same  functions  on 
different  machines.  In  this  sense,  system  and  network  management  APIs  are  considered 
productivity  tools  for  system  managers  and  system  management  application  developers. 

3.8.7. 1.1  Standards.  Table  3.8-51  presents  standards  for  system  administration  and  management 
APIs. 


TABLE  3.8-51  System  administration  and  management  APIs  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Management  Protocol  Profile*  (XMPP) 

0206  (11/93) 

Adopted 

(Approved) 

CPC 

NMF 

OMNlPoint  1  (Adopts  ISO  Profile  Sets  1 1 183-X,  12059- 
X.  end  12060-X,  include*  ISO/IEC  10164-X) 

OMNlPoint  1:1993 

Adopted 

(Approved) 

NPC 

IEEE 

—— 

1224:1993 

Adopted 

(Approved) 

NPC 

IEEE 

POSIX  System  Administration  •  Part  2:  Software 
Administration  (former  P1003.7.2) 

1387.2:1995 

Informational 

(Approved) 

NPC 

IEEE 

POSIX:  System  Administration  -  Put  3:  User  and  Group 
Administration 

1387.3:1996 

Informational 

(Approved) 

NPC 

’’TH W”""'"' 

BUS 

bfefiatoQMl 

1 

piliyiiii 

. 

■iiSs 

n  3*7.4 

XOpa 

i 

un 

_  (Superseded) 

3.8.7.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 
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a.  Croupe  Bull:  Consolidated  Management  Architecture  (CMA),  on  which  X/Open's 
XMP  and  OSF's  CM-API  are  based. 

b.  Tivoli  Systems:  Objcall  API,  which  is  incorporated  in  MRB  which  is  based  on 
Tivoli.  NOTE:  A  high-level  API,  such  as  the  Tivoli  Systems'  "objcall"  API  is  more 
suited  for  application  development  and  integration  than  for  management  tasks  such 
as  long-term  monitoring  of  system  devices. 

c.  Tivoli  Systems:  Application  Programming  Interface  (API)  to  objects. 

d.  Berkeley  Unix. 

e.  OSF:  OSF/1. 

3.8.7. 1.3  Standards  deficiencies.  All  traditional  Unix  system  administration  is  difficult.  Neither 
System  V  system  administration  facilities  nor  Berkeley  Unix  system  administration  facilities  were 
designed  for  a  distributed  networked  environment  Traditional  Unix  system  administration  is  not 
object-based  and  is  not  easily  extendable. 

3.8.7.1.4  Portability  caveats.  The  traditional  AT&T/USL  system  administration  facilities  are 
largely  different  from  and  incompatible  with  the  traditional  Berkeley  Unix  system  administration 
facilities. 

UI  specifies  the  AT&T/USL  system  administration  for  the  SVID.  OSF  provides  the  Berkeley 
Unix  system  administration  facilities  for  OSF/1 ,  except  for  the  System  V  accounting  facilities.  The 
SVID  and  OSF/1  system  administration  interfaces,  configuration  files,  and  procedures  are 
incompatible.  Most  of  the  shell  scripts  written  for  SVID-based  Unix  will  not  be  portable  to 
OSF/1  systems.  The  many  system  administration  configuration  files  required  by  POSIX  and  Unix 
are  not  portable  across  different  machines. 

3.8.7. 1.5  Related  standards.  The  following  standards  are  related  to  traditional  operating  system 
administration: 


a.  ISO  IS  9595/9596/CCITT  X.7 10/7 1 1 :  CM1S/CMIP  (Common  Management 
Information  Service/Protocol). 

b.  ISO  IS  7498: 1986/CCITT  X.700:  Management  Framework. 

c.  ISO  IS  10040: 1991:  Systems  Management  Overview. 

d.  ISO  IS  10 1 64- 1 : 1993/CCITT  X.730:  Object  Management  Function. 

e.  ISO  IS  101 64- 2 : 1993/CCITT  X.731:  State  Management  Function. 

f.  ISO  IS  10164-3: 1993/CCITT  X.732:  Attributes  for  Representing  Relationships. 
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g.  ISO  IS  10164-4:1992/CCITT  X.733:  Alarm  Reporting  Function. 

h.  ISO  IS  10164-5: 1993/CCITT  X.734:  Event  Report  Management  Function. 

L  ISO  IS  10164-6: 1993:Log  Control  Function. 

j.  ISO  IS  10164-7: 1992/CCITT  X.736:  Security  Alarm  Reporting  Function. 

k.  ISO  IS  10164-8: 1993  Security  Audit  Trail  Function. 

L  ISO  IS  10 1 64- 1 2: 1 994  Test  Management  Function. 

m.  ISO  IS  10165-1:1993/CCITT  X.720:  Structure  of  Management  Information. 

n.  ISO  IS  10165-2: 1992/CCITT  X.721:  Definition  of  Management  Information. 

o.  ISO  IS  10165-4:1992/CCITTX.722:GuidelmesfortheDefinitionofManaged 
Objects 

p.  ISODIS  10181-2.2:1993:  Authentication  Framework. 

q.  ISO  8824: 1990:  (Edition  2)  Specification  of  Abstract  Syntax  Notation  1  (ASN.  1 ). 

r.  ISO  8825: 1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1  (BER). 

s.  NIST  FIPS  146-2:  POSIT  (for  ASN.  1  and  BER  (related  to  ISO  8824  and  8825)). 

t.  NIST  FIPS  158- 1 :  X  Window  System  (X 1 1  Version  5). 

u.  NIST  FIPS  179-1:  Government  Network  Management  Profile  (GNMP). 

v.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

w.  X/Open:  G207.9/93:  Systems  Management  Reference  Model 

x.  X/Open:  G303:9/93:  Systems  Management:  Managed  Object  Guide  (XMOG). 

3.8.7.1.6  Recommendations.  The  PM  should  plan  to  use  X/Open's  XMPP  as  a  common  API  to 
CMIP  and  SNMP.  X/Open,  Unix  International,  and  OSF  specify  the  same  API,  although  they  call 
them  by  different  names  (XMP  and  CM- API).  The  XMP  and  CM- API  hide  some  of  the 
differences  between  CMIP  and  SNMP  and  eliminate  the  need  to  learn  two  different  syntaxes  to 
access  both  protocols. 
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The  OMNIPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
Version  3.0  of  the  NIST  Application  Portability  Profile. 
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3JJ.7.2  User/group  identification.  (This  BSA  appears  both  in  part  8  and  part  9.)  User/group 
identification  services  provide  traditional  system  administration  interfaces  for  administering  users 
and  groups.  These  services  are  mechanisms  for  system  and  network  administrators  to  use  when 
implementing  a  management  policy  across  a  system.  Administrators  can  use  the  services  to 
establish  domains  and  policies  for  management  throughout  the  system.  They  can  provide  the 
ability  for  applications  to  access  group  and  user  databases.  Users  can  set  up  their  own  areas  of 
management  and  policies  or  use  system  defaults  that  are  included  in  management  services. 

3.8.7.2.1  Standards.  Table  3.8-52  presents  standards  for  user/group  identification. 


TABLE  3,8-52  User/group  identification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IF.C 

Portable  Operating  Sy  Ham  Interface  (POSDC)  Put  1: 
System  API  (Replace*  ISO  9945*1:1990  and  incorporate! 
/SEE  1003.1b.  1003.1c,  and  1003.10 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphic!  Device  Interface, 
Volume  1  Mi cto *o ft  Win32  Programmer*'  Reference 
Manual,  1993,  Microioft  Pro** 

Win32  APIs 

Mandated 

(Approved) 

NPC 

IPFF. 

POSDC:  Syitem  Administration  •  Part  3:  User  and  Grotg> 
Administration 

1387.3:1996 

Emerging 

(Approved) 

NPC 

IEEE 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

mpp 

POSDC  Part  1 :  Syitem  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  [C  Language] 

1003. 1  i:  1995 

Informational 

(Approved) 

GPC 

NIST 

Computer  Security  Guideline*  for  Implementing  the 
Privacy  Act  of  1974 

FIPS  PUB  41:1975 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  on  Evaluation  of  Technique*  for  Automated 
Personal  Identification 

FTPS  PUB  48:1977 

Informational 

(Approved) 

3.5.7.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  Unix:  Centralized  User  and  Group  Management. 

b.  OSF/1  O.S.:  Centralized  User  and  Group  Management. 

3.8.7.2.3  Standards  deficiencies.  User  and  group  management  in  the  SV1D,  OSF/1,  and 
Berkeley  Unix  is  designed  for  a  centralized,  single  machine  environment.  No  Ada  bindings  exist 
for  user  and  group  management  standards. 

3.5.7.2.4  Portability  caveats.  System  V  Unix  and  the  SV1D  use  the  commands  "useradd"  and 
"groupadd"  to  add  a  new  user  or  group  to  the  system.  The  OSF  and  Berkeley  Unix  use  the 
commands  "adduser"  and  "addgroup"  to  do  the  same  thing. 

Although  the  functionality  defined  by  P1387.3  is  based  on  historical  user  and  group  administration 
practice,  no  commercial  products  which  conform  to  the  (draft)  standard  are  available  as  yet. 
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3.8.7.25  Related  standards.  The  following  standards  are  related  to  user  and  group  management 
or  user  and  group  management  standards: 

a.  ISO/1EC  9595:1991:  CMIS. 

b.  ISO/IEC  9596:1991:  CMP. 

c.  ISO/IEC  DIS  1 1578.2:  RPC. 

d.  Network  Management  Forum:  OMNIPoint  1. 

e.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets, 

f.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

g.  Internet  RFC  1213:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

3.8.7. 2.6  Recommendations.  The  mandated  standards  are  recommended. 
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3JS.7.3  Accounting  management.  (This  BSA  appears  in  part  8  and  part  9.)  Accounting 
management  services  provide  the  ability  to  cost  services  for  charging  and  reimbursement  An 
effective  cost  management  system  should  contribute  to  the  development  of  a  sound  investment 
strategy  that  recognizes  and  evaluates  cost  and  alternatives.  The  services  should  also  provide  for 
the  ability  to  measure  and  prioritize  resource  usage  and  to  monitor  assets  and  maintain  costing 
records  for  chargeback  purposes.  Costs  of  information  technology  services  should  be  capable  of 
being  apportioned  to  users,  and  reports  of  those  costs  should  be  capable  of  being  provided  to 
management  and  customers. 

3.8.7.3.1  Standards.  Table  3.8-33  presents  standards  for  accounting  management. 


TABLE  3.8-53  Accounting  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/TEC 

OSI  System*  Management,  Past  10:  Usage  Metering 
Function  for  Accounting  Purposes 

10164*10:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  System*  Management,  Part  13:  Summarization 
Function 

10164-13:1993 

Adopted 

(Approved) 

GPC 

NIST 

Guideline  for  Developing  and  Implementing  a  Charging 
Sytfem  for  Data  Processing  Service* 

FIPS  PUB  96:1982 

Adopted 

(Approved) 

3.5.7.3.2  Alternative  specifications.  The  following  soecifications  are  also  available: 

a.  OSF/1  O.S.:  Centralized  Accounting  Mgmt 

b.  Berkeley  BSD  4.3  Unix. 

3.8.7.3.3  Standards  deficiencies.  A  variety  of  different  chargeback  systems  are  using  different 
metrics  and  methods  that  are  causing  compatibility  problems  within  agencies  and  services.  The 
Unix  accounting  functions  are  designed  for  a  single  machine  environment. 

The  present  ISO  10164-10,  "Accounting  Metering  Function,"  and  10164-13,  "Summarization 
Function,"  standards  were  designed  with  a  networked  system  configuration  in  mind.  Little  work 
has  been  done  in  standards  groups  or  products  to  determine  how  to  use  these  standards  for  host 
configuration  management. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  are  planned,  few  are  currently  available  or  sufficiently  complete.  For  example,  these 
library  specifications  have  incomplete  object  definitions  for  modems,  OSI  routers,  and  transport 
connections. 

The  ISO  standards  require  ISO  CMIS/CMIP  for  the  communication  of  management  information 
and  ISO  OSI  networking  protocols,  and  do  not  interoperate  with  TCP/IP. 

No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 
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3A7.3.4  Portability  caveats.  OSF/1  uses  the  System  V  Unix  accounting  facilities.  Although  the 
OSF/1  and  System  V  accounting  systems  differ,  and  each  operating  system  has  extra  accounting 
functions,  the  use  of  the  same  accounting  facilities  eliminates  one  source  of  incompatibility. 

341.7.3.5  Related  standards.  The  following  standards  are  related  to  accounting  management  or 
accounting  management  standards: 

a.  ISO/IEC  7498:1986:  Management  Framework. 

b.  ISO/IEC  8571:1988:  FTAM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7.2 
and  5.3.1,  if  FTAM  functionality  are  required. 

c.  ISO/IEC  8650:1988:  ACSE,  as  specified  in  GOSIP  Version  2,  Section  4.2.7.1,  as 
modified  by  the  NMSIG  agreements  in  Part  18  of  the  OIW  Implementors 
Agreements. 

d.  ISO/IEC  8824: 1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.  1 ). 

e.  ISO/IEC  8825:1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1. 

f.  ISO/IEC  9041:1990  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7 .2  and  5.3. 1 ,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  ROSE,  as  specified  in  the  Remote  Operations  Part  1 :  Model 
Notation  and  Service  Definition  (ROSES),  and  the  Remote  Operations  Part  2: 
Protocol  Specification  (ROSEP),  and  as  modified  by  the  NMSIG  agreements 
clause  6.5. 

h.  ISO/IEC  9595:1991  CMIS. 

i.  ISO/IEC  9596: 1991  CMIP. 

j.  ISO/IEC  10165-1:1993:  SMI. 

k.  ISO/IEC  10165-2:1992:  DMI. 

l.  ISO/IEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISO/IEC  DIS  11578.2:  RPC. 

n.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7. 3  and  5.3.2,  if  message  handling  functionality  is  required. 
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o.  IEEE  1224: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327:1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  S  (Upper  Layer 
Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
Internets  based  on  TCP/IP. 

s.  Internet  RFC  1 157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1213:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  Network  Management  Forum:  OMNIPoint  1. 

v.  X/Open:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object  Management). 

3.8.7.3.6  Recommendations.  To  build  or  procure  account  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  within  the  ISO  10164  and  10165  standards  that  are  related 
to  these  requirements.  Finally,  they  must  explicitly  include  the  requirements  and  the  related 
standards  in  the  RFP. 

In  the  future,  the  NIST  plans  to  provide  a  capability  in  the  GNMP  to  integrate  the  present  GNMP 
with  SNMP. 
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3.8.7. 1  System  configuration.  (This  BSA  appears  both  in  part  8  and  part  9.)  System 
configuration  services  is  a  representation  of  the  components  and  component  parameters  of  a 
computer  system  (e.g.,  memory  boards,  amounts  of  memory,  memory  addresses,  particular 
interrupts,  networks,  network  addresses,  and  specific  peripherals  such  as  keyboards,  disk  drives, 
terminals,  mice  or  other  input  devices,  and  specialized  instruments).  Clearly,  every  computer 
must  have  a  way  to  do  this.  System  configuration  also  refers  to  the  automation  of  this  procedure 
(i.e„  automated  system  configuration)  and  the  ability  to  configure  the  system  on-line.  On-line 
configuration  refers  to  the  ability  for  system  administrators  to  make  dynamic  configuration 
changes,  while  users  are  working  on-line,  rather  than  having  to  take  the  system  down. 

3.8.7.4.1  Standards.  Table  3.8-54  presents  standards  for  system  configuration. 


TABLE  3.8-54  System  configuration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

CPC 

NMF 

OMNIPoint  I  (Adopt*  ISO  Profile  Set*  1 1 183-X,  12059- 
X  and  12060-X  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted  1 

(Approved)  ] 

IPC 

ISO/IEC 

OSI  Systems  Management,  Put  1:  Object  Management 
Function 

10164-1:1993 

Informational  1 
(Approved)  E 

[PC 

ISO/TEC 

OSI  Systems  Management,  Pan  2:  State  Management 
Function 

10164-2:1993 

Informational  1 
(Approved)  1 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  3:  Attributes  for 
Representing  Relationship* 

10164-3:1993 

Informational  1 
(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  12:  Test  Management 
Fwction 

10164-12:1994 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

3.8.7.4.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.7.4.3  Standards  deficiencies.  The  present  ISO  10164-3,  "Attributes  for  Representing 
Relationships,"  and  10164-12,  "Test  Management  Function,"  standards  were  designed  with 
network  configuration  in  mind.  Theoretically,  these  standards  should  be  able  to  be  used  for 
configuration  management  of  any  computer  system.  Until  now,  very  little  work  has  been  done  in 
this  area,  either  in  standards  groups  or  in  products.  Exactly  how  these  standards  should  be  used 
in  host  management  is  undetermined. 

Versions  1.0  and  2.0  of  the  GNMP  specify  only  network  management  capabilities.  Not  until 
Version  3.0  is  available  will  the  GNMP  specify  the  management  information  required  for  general 
system  management,  such  as  host  computer  configuration  and  management,  operating  systems 
management,  and  database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CM1S/CM1P  for  the 
communication  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for  the 
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GNMP  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP  also.  One  reason  for 
this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  bindings  exist  for  the  configuration  management  standards  or  consortia  specifications. 
3JI.7.4.4  Portability  caveats.  Unknown 

3.R.7.4.5  Related  standards.  The  following  standards  are  related  to  system  configuration  or 
system  configuration  standards: 

a.  1SO/IEC  7498-4: 1989:  Management  Framework. 

b.  1SO/IEC  8571:1988:  File  Transfer,  Access,  and  Management  (FTAM),  a? 
specified  in  OOSIP  Version  2  Sections  4.2.7.2  and  5.3.1,  if  FTAM  functionality 
are  requirrd. 

c.  ISO/IEC  8650: 1988:  ACSE,  as  specified  in  GOSIP  Version  2,  Section  4.2.7. 1 ,  as 
modified  by  the  Network  Management  S1G  (NMSIG)  agreements  in  Part  1 8  of  the 
OS!  Implementors'  Workshop  (OIW)  Implementors  Agreements. 

d.  ISO/IEC  8824:1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

e.  ISO/IEC  8825:1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1 . 

f.  ISO/IEC  9041 : 1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3. 1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  Remote  Operations  Service  Element  (ROSE),  as  specified  in 
the  Remote  Operations  Part  1 :  Model  Notation  and  Service  Definition  (ROSES), 
and  the  Remote  Operations  Part  2:  Protocol  Specification  (ROSEP),  and  as 
modified  by  the  NMSIG  agreements  clause  6.5. 

h.  ISO/IEC  9595:1991:  CMIS. 

i.  ISO/IEC  9596:1991:  CM1P. 

j.  ISO/IEC  10165-1:1993:  Structure  of  Management  Information  (SMI). 

k.  ISO/IEC  10165-2:1992:  Definition  of  Management  Information  (DMI). 

l.  ISO/IEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISO/IEC  DIS  1 1578.2:  Remote  Procedure  Call. 
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n.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

o.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

p.  Comite  Consultatif  International  de  Telegraphique  et  Telephonique  (CCITT) 
X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7. 3  as  id  5.3.2,  if  message  handling  functionality  is  required. 

q.  NIST  OSI  Implementors  Workshop  (OFW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

s.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1213:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  C315:5/94:  OS  I- Abstract-Data  Manipulation  API  (XOM)  (Object 
Management). 

3.8.7.4.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 

To  build  or  procure  configuration  management  applications,  users  must  identify  the  system 
management  functions  that  are  applicable  to  their  requirements.  Then  they  must  identify  the 
various  ISO  10164  and  10165  standards  whose  specifications  are  related  to  these  requirements. 
Finally,  they  must  include  their  explicit  requirements  and  the  related  standards  in  the  RFP. 
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3.8.7  J  Communication  of  management  information.  (This  BSA  appears  in  part  8  and  part  9.) 
Communication  of  management  information  refers  to  a  mechanism  and  protocol  with  extensions 
specifically  geared  to  the  communication  of  data  and  information  used  by  system  management  and 
network  management  applications  for  monitoring  and  controlling  resources.  This  management 
information  may  be  shared  between  management  processes  and  structured  according  to  the 
requirements  of  those  processes. 

3.8.7.5.I  Standards.  Table  3.8-3S  presents  standards  for  communication  of  management 
information. 


TABLE  3.8-55  Communication  of  management  information  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IlljH 

IPC 

1AB 

Simple  Network  Management  Protocol  (SNMP) 

Standard  15/RFC- 
1157 

Mandated 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profiles  -  Internet  Network  Management 
Profile  for  DoD  Communication! 

MIL-STD-2045- 

17507:7/94 

Informational 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profile  Sets  1 1 183-X,  12059- 
X.  and  1206O-X,  include!  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Service*  (CM1S) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  •  Open  System*  Interconnection  • 
Common  Management  Information  Protocol  (CMIP)  -  Part 

1 :  Specification  (Include*  amendment  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Elements  of  Management  Information  Relating  to  OSI 
Netwoik  Layer  Standards 

10733:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

10742:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 

CPC 

X/Open 

Management  Protocol  Profiles  (XMPP) 

C206  (11/93) 

Informational 

(Approved) 

CPC 

IETF 

Protocol  Operations  for  Simple  Network  Management 
Protocol,  version  2  (SNMPv2) 

RFC  1448:1993 

Informational 

(Approved) 

T 

Hill 

MlSM-wftniiUlwC*.  MMMWf  11*71 
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US 

mm 
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3.8.7.S.2  Alternative  specifications.  Hewlett-Packard's  Postmaster,  on  which  the  OSF  DME's 
CMIP  and  Simple  Network  Management  Protocol  (SNMP)  implementations  are  based,  is  also 
available. 


3.8.7.S.3  Standards  deficiencies.  With  its  object-oriented  approach,  CMIS/CM1P  has  a  relatively 
expensive  initial  application  implementation  cost.  This  flaw  is  offset  by  a  low  maintenance  cost, 
because  CMIS/CMIP  allows  objects  to  be  added,  and  an  associated  level  of  management  to  be 
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provided,  at  a  small  incremental  cost  There  is  no  standard  API  to  CMIS/CMIP.  Only  a  limited 
number  of  narrowly  focused  applications  are  implemented  with  it  It  lacks  a  complete  set  of 
associated  object  definitions  needed  for  network  management  and  sufficient  associated  security 
standards. 

The  SNMP  is  a  simple  request-and-reply  protocol.  It  performs  all  its  operations  using  a  fetch- 
and-store  paradigm,  rather  than  defining  a  large  set  of  commands.  Effectively,  the  SNMP 
network  manager  is  restricted  to  only  two  commands  that  are  performed  on  Management 
Information  Base  (MIB)  data  items:  "set"  and  "get."  Variables  are  retrieved  (get)  or  modified 
(set).  All  other  operations  are  defined  as  side-effects  of  the  "set"  operation. 

The  SNMP's  chief  disadvantage  is  the  fact  that  its  simplicity  severely  limits  the  protocol's  ability  to 
satisfy  users'  requirements  for  event  reporting,  sufficient  control,  and  extensibility.  Because 
SNMP  is  so  simplistic  and  limited,  it  provides  more  of  a  monitoring  and  data  gathering  capability 
than  a  management  function. 

The  SNMP  accommodates  only  limited  event  reporting  by  means  of  the  "trap"  mechanism.  Other 
events  must  be  discovered  by  the  managing  node  by  means  of  periodic  polling.  Its  simplicity 
compromises  its  ability  to  support  consistent  or  extensive  addressing.  It  has  limited  security 
capabilities,  and  does  not  support  threshold-driven  performance  notification  except  indirectly 
through  side  effects  or  "set"  operations  on  MIB  items.  SNMP  cannot  be  extended  easily. 

The  SNMP  has  a  high  maintenance  cost  Although  the  first  implementation  of  SNMP  is  relatively 
inexpensive,  SNMP's  simplicity  so  severely  limits  its  extensibility  that  future  SNMP  developments 
are  more  likely  to  occur  in  the  form  of  new  proprietary  and  standard  Management  Information 
Bases  (MIBs)  rather  than  as  SNMP  enhancements.  Each  additional  MIB  will  require  changes  and 
additions  to  its  existing  specific  applications  to  support  new  functions.  New  MIBs  also  will 
require  a  unique  application  code  to  be  developed,  modified,  documented,  and  supported.  MIB 
development  and  maintenance  can  result  in  a  high  cost  to  users  and  vendors  and  present  a  major 
SNMP  concern. 

The  SNMP  lacks  an  object-oriented  approach  to  network  management.  The  lack  of  object 
orientation  is  a  major  factor  limiting  the  SNMP's  extensibility  and  its  ability  to  support  legacy 
systems,  support  system  and  network  management,  and  make  complex  distributed  system 
management  more  intuitive. 

It  lacks  the  ability  to  manage  a  network  of  networks  in  which  different  managers  must  interact  on 
a  peer-to-peer  basis. 

Because  the  SNMP  cannot  be  extended  easily,  and  extensions  require  changes  to  SNMP 
applications,  developing  new  SMP  products  rather  than  retooling  existing  ones  probably  will  be 
less  costly. 
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The  future  of  SMP  is  uncertain  because  it  is  unclear  whether  vendors  will  want  to  develop  new 
products  for  a  protocol  that  is  incompatible  with  the  major  systems  management  standards  today 
(e.g.,  from  ISO,  NMF,  X/Open,  and  OSF).  SMP  is  still  less  functional  than  CMIS/CMIP. 

The  SMP  is  not  an  Internet  standard.  Although  developed  in  response  to  a  request  issued  by  the 
Internet  Engineering  Task  Force  (IETF)  for  an  improved  SNMP,  SMP  was  developed  outside  the 
IETF.  Furthermore,  the  SMP  developers  do  not  plan  to  submit  it  as  a  proposed  Internet  standard. 
They  feel  that  submitting  SMP  to  a  committee  would  subject  it  to  alteration  and  a  lengthy  review, 
and  would  slow  down  development  of  a  coherent  technology. 

SMP  is  not  accepted  by  groups  such  as  the  Network  Management  Forum  (NMF),  X/Open,  OSF, 
and  the  National  Institute  of  Standards  and  Technology  (NIST).  These  groups  are  resistant  to 
SMP  because  it  lacks  an  object-oriented  approach  to  network  management.  Despite  the 
improvements,  without  object  orientation,  SMP  is  still  incompatible  with  the  ISO  and  NMF 
network  management  model,  as  well  as  with  the  OSFs  Distributed  Management  Environment 
(DME)  and  X/Open's  systems  management  specifications.  Vendors  moving  from  SNMP  to  SMP 
may  find  it  more  cost  effective  to  develop  new  SMP  products. 

SMP  is  not  easily  extensible,  and  like  SNMP,  is  expensive  to  extend.  This  is  largely  due  to  SMP's 
lack  of  an  object-oriented  approach  to  network  management. 

3.8.7.5.4  Portability  caveats.  Nonstandard  SNMP  MIB  definitions  have  proliferated. 

The  SNMP  MIB  is  tailored  to  accommodate  only  Internet  equipment.  Despite  the  X/Open,  OSF, 
and  former  UI  (now  X/Open)  consolidated  interface  to  CMIP  and  SNMP  (X/Open  Management 
Protocol  (XMP)  and  CM- API),  without  object-orientation  SNMP  is  still  incompatible  with  the 
ISO  and  NMF  network  management  model,  as  well  as  with  the  OSF's  Distributed  Management 
Environment  (DME)  and  X/Open's  systems  management  specifications. 

SNMP's  design  does  not  lend  itself  to  migration  from  and  coexistence  with  legacy  systems.  For 
example,  SNMP  does  not  support  the  ability  to  send  the  same  operation  to  different  classes  of 
objects  (an  important  concept  known  in  this  context  as  "polymorphism,"  which  CMIS/CMIP 
supports). 

3.8.7.5.5  Related  standards.  The  following  standards  are  related  to  management  information 
communication  standards: 

a.  ISO/IEC  7498: 1986:  Management  Framework. 

b.  ISO/IEC  8326:1987  and  8327:1987:  Connection-Oriented  Session  Service  and 
Connection-Oriented  Session  Protocol,  respectively. 

c.  ISO/IEC  8326  AD  2:  Connection-Oriented  Session  Service  -  Incorporation  of 
Unlimited  User  Data, 
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d.  ISO/IEC  8327  AD  2:  Connection-Oriented  Session  Protocol  -  Incorporation  of 
Unlimited  User  Data. 

e.  ISO/IEC  8571:1988:  FT  AM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7.2 
and  5.3. 1 ,  if  File  transfer,  Access,  and  Management  functionality  are  required. 

f.  ISO/IEC  8649: 1988  and  8650: 1988:  Association  Control  Service  Element  (ACSE) 
and  Association  Control  Protocol  (ACP),  as  specified  in  GOSiP  Version  2, 

Section  4.2.7.1,  as  modified  by  the  NMSIG  agreements  in  Part  18  of  the  OIW 
Implementors  Agreements. 

g.  ISO/IEC  8822: 1988  and  8823: 1988:  Connection-Oriented  Presentation  Service 
and  Connection-Oriented  Presentation  Protocol,  respectively. 

h.  ISO/IEC  8824:1990:  Abstract  Syntax  Notation  1  (ASN.l). 

i.  ISO/IEC  8825:1990:  Basic  Encoding  Rules  (BER)  for  ASN.l . 

j.  ISO/IEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7 .2  and  5.3.1,  if  virtual  terminal  functionality  is  required. 

k.  ISO/IEC  9072-1:1989  and  9072-2:1989:  ROSE  and  Remote  Operations  Protocol 
(ROP),  as  specified  in  the  Remote  Operations  Part  1 :  Model  Notation  and  Service 
Definition  (ROSES)  and  the  Remote  Operations  Part  2:  Protocol  Specification 
(ROSEP),  and  as  modified  by  the  NMSIG  agreements  clause  6.5. 

l.  ISO/IEC  10165-1:1993:  SMI. 

m.  ISO/IEC  10165-2:1992:  DMI. 

n.  ISO/IEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

o.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

p.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7,  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

q.  Open  Software  Foundation  Distributed  Computer  Environment  (DCE):  Remote 
Procedure  Call  (RPC)  Service  Definition. 
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r.  Plan  to  use  IEEE  1327  Object  Management  API,  or  X/Open's  XOM  (on  which 
1327  is  based)  to  simplify  the  management  of  networked  managed  resources  in  a 
CMIP  environment  (See  system  management  APIs  BSA  in  part  8  for  more 
information.) 

s.  RFC  1006:1987:  ISO  transport  services  on  top  of  the  TCP:  version  3  (IAB  Std 
35). 

3.8.7.S.6  Recommendations.  All  new  systems  and  systems  undergoing  major  upgrades  should 
use  the  Internet  Architecture  Board  (IAB)  STD  15,  SNMP  (RFC  1 157).  Those  persons 
conducting  procurements  that  involve  IAB  standards  should  review  the  latest  version  of  the  IAB 
official  protocol  standards  list  to  ensure  that  the  appropriate  RFCs  are  specified. 

The  PM  should  plan  to  use  CMIS/CMIP  for  OSI/GOSIP  networks  and  existing  TCP/IP 
networks,  because  SNMP  does  not  have  the  required  functionality  to  manage  distributed 
networks  and  is  very  expensive  to  maintain. 

Until  environments  become  distributed,  SNMP  is  a  suitable  solution  for  stand-alone  local  area 
networks. 

The  PM  also  should  plan  to  use  either  X/Open's  XMP  or  OSF's  CM- API  (they  are  the  same)  as  a 
common  API  to  CMIP  and  SNMP.  (See  the  system  administration  and  management  APIs  BSA  in 
part  8  for  more  information). 

The  CMOT  users,  vendors,  and  applications  should  be  aware  of  some  of  the  functional  differences 
between  OSI  managed  systems  and  Internet  agents  because  CMIS/CMIP's  more  sophisticated  and 
additional  features  may  be  difficult  to  map  reliably  to  TCP/IP  and  SNMP. 

A  common  protocol  API  should  be  used  to  access  CMIP  and  SNMP.  X/Open,  Unix 
International,  and  OSF  specify  the  same  API.  X/Open  and  Unix  International  call  the  API  "XMP" 
(X/Open  Management  Protocol);  OSF  calls  the  same  protocol  CM- API  (Consolidated 
Management  API).  Although  XMP  and  CM-API  provide  an  extra  call  specific  to  SNMP,  because 
the  SNMP  "GetNext"  function  call  does  not  work  in  an  OSI  environment,  the  consolidated 
management  protocol  API  provides  the  union  of  the  CMIP  and  SNMP  protocols  and  service 
primitives  consistently.  It  hides  some  of  the  differences  between  CMIP  and  SNMP.  For  most 
work,  programmers  and  system  managers  need  to  learn  only  a  single  syntax  to  access  both 
protocols. 
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3.8.T.6  Error  and  event  logging.  (This  BSA  appears  both  in  part  8  and  part  9.)  Error  logging  is 
the  automatic  logging  of  errors  and  events  to  a  log  (special  file)  to  avoid  system  or  network  faults 
(by  detecting  that  the  operation  of  a  component  is  approaching  the  edge  of  its  operational  range) 
and  to  provide  a  historical  record  that  can  be  studied  to  diagnose  faults  after  their  occurrence  and 
perhaps  prevent  their  happening  in  the  future. 

On  the  detection  of  events  of  interest,  the  operating  system  may  automatically  write  *he  encoded 
event  to  the  system  log  and/or  may  notify  a  process  of  the  occurrence.  This  is  certainly  the  case 
when  an  error  with  a  high  severity  level  is  detected.  Logging  or  notification  may  occur  at  any  time 
in  the  operation  of  a  system.  They  may  occur  when  an  application  or  the  operating  system  has 
detected  an  error,  when  an  event  has  been  generated  during  event  classification  (especially  if  the 
event  is  indicative  of  imminent  failure  of  a  component),  or  when  an  event  is  severe  and  requires 
the  immediate  attention  of  a  process  and  when  a  corrective  action  is  taken,  such  as  when  a 
processor(hardware)  or  process(software)  is  being  registered  for  service. 

3. 8.7. 6.1  Standards.  Table  3.8-56  presents  standards  for  error  and  event  logging. 


TABLE  3.8-56  Error  and  event  logging  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

NMP 

OMNIPoint  1  (Adopu  ISO  Profile  Seta  11183-X,  12059- 
X.  end  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

CPC 

X/Op «n 

Single  UNIX  Specification,  Sy  item  Interface  Definition*, 
Vernon  2,  luue  5 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  Sy* tern  Interface*  and  Header*, 
Vernon  2, Iisue  5 

C606  (2/97) 

Emerging 

(Approved) 

IPC 

ISO/IEC 

OSI  System*  Management,  Part  4:  Alarm  Reporting 
Function 

10164-4:1992 

Informational 

(Approved) 

IPC 

ISOAEC 

OSI  Systems  Management,  Part  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  6:  Log  Control  Function 

10164-6:1993 

Informational 

(Approved) 
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3.8.7.6.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Banyon  Systems'  Network  Event  Logger  (NeL)  (from  Wang  Laboratories)  on 
which  OSF's  Event  Notification  Component  is  based. 
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b.  Banyon  Systems'  PC  library  for  the  Network  Event  Logger  (NeL),  which  filters 
and  logs  PC  events  locally  and  sends  them  to  a  Network  Event  Logger  server  on  a 
host  system  for  further  processing. 

34.7.6 3  Standards  deficiencies.  No  Ada  bindings  are  available  for  any  of  the  consortium's 
system  management  Error  Logging  Components. 

34.7.6.4  Portability  caveats.  Portability  problems  related  to  the  existing  standards  are  unknown. 
3.8.7.65  Related  standards.  The  following  standards  are  related  to  error  logging  standards: 

a.  ISO/IEC  DIS  1 1578.2:  OSI  -  RPC  (Replaces  DIS  1 1578  PT  1  Thru  PT  4). 

b.  NIST  APP  -  Special  Pub.  550-230: 1995. 

c.  OSF:  DCE  RPC  Component. 

d.  USL/Sun  Microsystems:  Open  Network  Computing  (ONC)  RPC  Component. 

3.8.7.6.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POS1X.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3X7.7  Subsystem  management.  (This  BSA  appears  both  in  part  8  and  part  9.)  Subsystem 
Management  Service  (SMS)  is  a  product  that  controls  the  execution  of  system  processes  (usually 
daemons).  It  ensures  that  related  processes  are  started  (or  stopped)  in  the  proper  sequence.  It 
also  provides  a  standard  systems  administration  command  syntax  to  start/stop  these  processes, 
and  the  specification  for  an  RPC  interface  that  could  be  embedded  into  daemons  to  allow 
administrator  interaction.  Without  SMS,  the  commands  to  start  these  processes  are  embedded  in 
the  system  startup  file.  There  is  no  mechanism  to  ensure  that  one  daemon  is  ready  before  starting 
a  related  one.  To  stop  a  daemon,  the  administrator  needs  to  know  the  syntax  of  the  appropriate 
command,  and  needs  to  know  which  other  related  daemons  also  need  to  be  stopped.  If  a  daemon 
dies,  the  administrator  needs  to  know  which  related  processes  to  stop,  and  the  proper  sequence  to 
restart  them. 

3.8.7.7.I  Standards.  Table  3.8-37  presents  standards  for  subsystem  management 


TABLE  3.8-57  Subsystem  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

HI 

m 

111 

ail 

m 

3.8.7.7.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3X7.7  J  Standards  deficiencies.  There  are  no  products  currently  using  the  OSF  DME  SMS 
specifications.  The  software  available  from  the  OSF  could  be  used  as-is,  although  it  is  intended  to 
be  used  by  third-party  vendors  as  the  basis  for  products. 

There  are  also  no  daemons  that  implement  the  SMS  RPC  interface,  except  for  the  ones  that  come 
with  OSF  DME.  Therefore  the  SMS  is  required  to  use  Signals  to  stop  daemons,  which  may  have 
unpredictable  results  if  the  daemon  does  not  catch  the  signal  correctly. 

3X7.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3X7.7 .5  Related  standards.  The  following  standard  is  related  to  subsystem  management. 

a.  OSF  DCE  Remote  Procedure  Call  (RPC) 

3X7.7.6  Recommendations.  There  are  no  recommendations. 
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3.S.7.8  Event  management  Event  management  and  notification  services  allow  system  managers 
and  system  administrators  to  be  informed  that  a  predefined  system  or  network  event  of  interest 
(e.g.,  additional  resources  needed)  has  occurred,  so  that  the  event  may  be  managed  in  a 
predefined  way  that  prevents  network  or  system  problems.  Event  management  is  related  closely 
to  fault  and  performance  management,  in  that  each  of  these  services  could  make  use  of  event 
management  to  log,  track,  and  provide  alerts  based  on  relevant  events. 

3.8.7.8.1  Standards.  Table  3.8-S8  presents  standards  for  event  management 


TABLE  3.8-58  Event  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  I  (AdopU  ISO  Profile  Set!  11I83-X.  12059- 
X,  and  12060-X,  include!  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

GPC 

NIST 

Stable  Implementation  Agreement!  for  Open  Sytfem 
Environment!,  Ver.  8,  Ed.  1 

Special  Pub.  500- 
224:12/94 

Informational 

(Approved) 

[PC 

ISO/IEC 

OSI  System*  Management,  Part  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

[PC 

ISO/EC 

Portable  Operating  Sy  *tam  Interface  (PGSDC)  Part  1 : 
System  API  (Replaces  ISO  9945-1:1990  and  incorporate! 
IEEE  1003,1b.  1003.1c,  and  1003.11) 

9945-1:1996 

Informational 

(Approved) 

NPC 

IEEE 

iMagMsa 

1003.1b:1993 

Informational 

(Approved) 

inpn 

_ 1 

3.8.7.8.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Banyon  Systems'  Network  Event  Logger  (from  Wang  Laboratories)  on  which 
OSF's  Event  Notification  Component  is  based. 

b.  Banyon  Systems'  PC  library  for  the  Network  Event  Logger,  which  filters  and  logs 
PC  events  locally  and  sends  them  to  a  Network  Event  Logger  server  on  a  host 
system  for  further  processing.  The  OSF  DME's  PC  Error  Logging  Component  is 
based  on  this  Banyon  Systems'  PC  library. 

3.8.7.8.3  Standards  deficiencies.  None  of  the  event  notification  components  in  any  of  the 
consortia  management  systems  are  compatible  with  the  IEEE  P1003. lb  specifications  for  event 
notification.  OSF  DME  event  management  is  intended  to  be  used  as  the  basis  for  commercial 
management  systems,  but  is  not  currently  supported  by  any  products. 

3.8.7.5.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 
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3 &.7.HJS  Related  standards.  The  following  standards  are  related  to  event  management  and 
notification  standards: 

a.  ISO/IEC  DIS  1 1578.2:  RPC  (Replaces  DIS  1 1578  PT  1  Thru  PT  4.) 

b.  NIST  APP  -  Special  Pub.  500-230:  1 995. 

c.  OSF:  Distributed  Computing  Environment  (DCE)  Remote  Procedure  Call 
Component. 

d.  USL/Sun  Microsystems:  Open  Network  Computing  (ONC)  Remote  Procedure 
Call  (RPC)  Component 

e.  NIST  FIPS  179-1:1995:  Government  Network  Management  Profile  (GNMP). 

f.  ISO/IEC  9596-1:1991:  OSI CMIP,  Part  1:  Specification. 

g.  IAB:  RFC  1157:  SNMP. 

S.8.7.8.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 
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3.8.7.9  Performance  management.  (This  BSA  appears  in  part  8  and  part  9.)  Performance 
management  provides  services  and  interfaces  for  tuning  systems  and  subnetworks  to  meet 
individual  performance  requirements.  Performance  management  enables  the  behavior  of 
resources  and  the  effectiveness  of  communication  activities  to  be  evaluated.  It  includes  functions 
to:  gather  statistical  information;  maintain  and  examine  logs  of  system  state  histories;  determine 
system  performance  under  natural  and  artificial  conditions;  and  alter  system  modes  of  operation 
for  the  purpose  of  conducting  performance  management  activities.  Performance  management 
may  make  use  of  event  management  facilities. 

3.8.7.9.1  Standards.  Table  3.8-59  presents  standards  for  performance  management 


TABLE  3.8-S9  Performance  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NIST 

FIPS  PUB 
144:1985 

Adopted 

(Approved) 

CPC 

NMF 

OMNIPoinl  1  (Adopt*  iso  Profile  Sea  1 1 183-X,  12059- 
X,  and  1206O-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Syitem*  Management,  Part  1 1 :  Metric  Object*  and 
Attribute* 

10164-11:1994 

Informational 

(Approved) 

GPC 

NIST 

Guideline  on  Computer  Performance  Management:  An 
Introduction 

FIPS  PUB  49:1977 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  for  the  Meuunement  of  Interactive  Computer 
Service  Re* pome  Time  and  Turnaround  Time 

FIPS  PUB  57:1978 

Informational 
(Approved)  | 

CPC 

NIST 

Government  Networic  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational  N 
(Approved) 

GPC 

NIST 

Guideline*  for  Measurement  of  Remote  Batch  Computer 
Service 

FIPS  PUB  72:1980 

informational 

(Approved) 

3.8.7.9.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.7.9.3  Standards  deficiencies.  The  present  10164- 1 1  ("Workload  Monitoring  Function)  and 
generic  10165-xx  standards  were  designed  with  network  configuration  in  mind.  Theoretically, 
they  should  be  able  to  be  used  for  configuration  management  of  any  computer  system.  Little 
work  has  been  done  in  this  area,  either  in  standards  groups  or  in  products.  Exactly  how  these 
standards  should  be  used  in  host  management  is  undetermined.  Standards  for  system  performance 
measurement  are  needed. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  and  support  performance  management  of  network  resources  are  planned,  few  are 
currently  available  or  sufficiently  complete.  For  example,  these  library  specifications  have 
incomplete  object  definitions  for  modems,  OSI  routers,  and  transport  connections.  Based  on 
needs  of  the  U.S.  Federal  Government  (as  shown  by  NIST  surveys),  the  GNMP  added  more 
object  class  specifications  and  definitions,  These  include  the  following  objects:  LANs,  X.25 
WANs,  ISDN,  FDD1,  modems,  bridges,  links,  and  a  rudimentary  capability  to  manage  OSI 
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routers  and  transport  connections.  Phase  2  GNMP  objects  also  will  include  protocol  software 
(layers  3-7),  routers,  terminal  servers,  MTAs,  PBXs,  and  circuit  switches. 

Versions  1.0  and  2.0  of  the  GNMP  currently  specify  only  network  management  capabilities.  Not 
until  Version  3.0  will  the  GNMP  specify  the  management  information  required  for  general  system 
management,  such  as  host  computer  configuration  and  management,  operating  systems,  and 
database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CMIS/CMIP  for  the 
communication  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for  the 
GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP.  One 
reason  for  this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  binding  is  available  for  the  ISO  system  management  standards. 

Performance  management  could  make  use  of  generalized  event  management  facilities,  but  most 
products  currently  implement  their  own  event  management. 

3.8.7.9.4  Portability  caveats.  Portability  problems  related  to  «  .<•  existing  specific  i  •  ■ 
unknown. 

3.8.7.9.5  Related  standards.  The  following  standards  are  related  to  performance  management  or 
performance  management  standards: 

a.  ISO/IEC  7498-4: 1989:  Management  Framework. 

b.  ISO/IEC  8-*57 1 : 1988:  FTAM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7. 2 
and  “5.3.1,  if  FTAM  functionality  are  required. 

c.  ISO/IEC  8650: 1988:  Association  Control  Service  Element  (ACSE),  as  specified  in 
GOSIP  Version  2,  Section  4.2.7. 1,  as  modified  by  the  NMSIG  agreements  in  Part 
18  of  the  OIW  Implementors  Agreements. 

d.  ISO/IEC  8824:1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

e.  ISO/IEC  8825:1990:  Specification  of  Basic  Encoding  Rules  for  ASN.l. 

f.  ISO/IEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3.1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072:1989:  ROSE,  as  specified  in  the  Remote  Operations  Pan.  1:  Sodel 
Notation  and  Service  Definition  (ROSES),  and  the  Remote  Operations  Part  2: 
Protocol  Specification  (ROSEP),  and  as  modified  by  the  NMSIG  agreements 
clause  6.5. 
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h.  ISO/IEC  9595: 1991:  CMIS. 

L  ISO/1EC  95%:  1991:  CMIP. 

j.  ISO/IEC  10165-1:1993:  SMI. 

k.  ISO/':  .C  10165-2:1992:  DM1. 

L  ISO/IEC  101654:1992:  GDMO. 

m.  ISO/IEC  DIS  11578.2:  RPC. 


n.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

o.  IEEE  1224: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327:1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7,  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 


s.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1 158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  C315:5/94:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object 
Management). 


3.8.7.9.6  Recommendations.  To  procure  performance  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  in  the  ISO  10164  and  10165  standards  related  to  these 
requirements.  Finally,  they  must  include  their  requirements  and  the  related  standards  in  the  RFP. 


The  OMNIPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
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Version  3.0  of  (he  NIST  Application  Portability  Profile.  OMNIPoint  adopts  the  ISO  10164  and 
10165  series  of  standards. 

FIPS  144  is  a  mandatory  standard  according  to  the  Federal  ADP  and  Telecommunications 
Standards  Index  and  shall  be  used  if  it  satisfies  the  user’s  requirements. 
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3X8  Fault  management  services.  A  fault  condition  arises  whenever  a  malfunction  or  abnormal 
behavior  results  or  may  result  in  an  error,  outage,  or  degradation  of  services.  Fault  Management 
services  allow  a  system  to  minimize  the  impact  of  faults  on  a  system.  These  services  are  designed 
to  detect  events  of  interest,  namely,  errors,  events  indicative  of  imminent  failures,  and  events 
associated  with  recovery  from  the  effects  of  faults.  This  is  accomplished  by  providing  services  to 
detect  events  of  interest,  collect  the  associated  state  of  these  events,  encode  the  events,  log  the 
encoded  events  together  with  their  associated  states,  provide  notification  of  such  events,  classify 
such  events,  recover  from  errors,  and  reconfigure  the  system.  The  services  have  two  aspects  to 
them,  those  that  support  system  recovery  from  errors  while  it  is  running,  and  those  that  support 
the  maintainability  of  the  system.  For  example  when  a  disk  read  retry  threshold  has  been  exceeded 
this  may  indicate  a  pending  disk  failure.  In  order  that  the  system  maintain  its  fault  tolerant 
characteristics  and  maintain  high  availability  a  spare  or  backup  contingency  should  be  available. 
Fault  management  has  four  main  functional  areas,  detection,  logging  and  notification,  diagnosis, 
and  corrective  action. 

Faults  in  a  system  are  not  detected  directly,  they  are  inferred  from  their  effects,  namely  the  errors 
and  /  or  anomalous  events  that  arise  as  a  result  of  these  faults.  The  following  definitions  of  fault, 
error  and  failure  are  used  in  the  discussion  that  fo'lows.  A  failure  results  when  the  service  that  a 
system  delivers  no  longer  complies  with  the  system  specification,  which  is  assumed  to  be 
authoritative.  An  error  is  that  part  of  the  system  state  which  may  lead  to  failure.  Finally,  a  fault  is 
the  assigned  or  hypothesized  cause  of  an  error.  Faults  are  managed  in  two  ways.  One  way  is  to 
continue  processing  in  the  face  of  errors  in  the  system,  and  the  other  is  to  diagnose  and  passivate 
a  fault  (that  is  to  prevent  it  from  being  reactivated)  or  to  diagnose  and  isolate  the  fault,  so  that  the 
faulty  component  may  be  repaired. 

3.8.8.1  Fault  management.  (This  BSA  appears  in  part  8  and  part  9.)  Fault  management 
services  allow  a  system  to  react  to  the  loss  or  incorrect  operation  of  system  components.  Fault 
management  services  encompass  services  for  fault  detection,  isolation,  diagnosis,  recovery,  and 
avoidance.  Fault  management  may  make  use  of  event  management  facilities.  In  practice,  fault 
management  and  performance  management  products  often  incorporate  event  management 
functions. 

3.8.8.1.1  Standards.  Table  3.8-60  presents  standards  for  fault  management. 


TABLE  3,8-60  Fault  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

1  CPC 

NMF 

OMNtPoim  l  (AdopU  ISO  Profile  SeU  1 1 183-X,  12059- 
X.  »nd  I2060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OS1  Systems  Management,  Pan  4:  Alarm  Reporting 
Function 

10164-4:1992 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

OSI  Syitema  Management,  Put  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

1PC 

ISOAEC 

OSI  Syefcau  Maugeaeot,  Put  6:  Lo(  Control  Function 

10164-6:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  System  Management,  Put  12:  feet  Management 
Auction 

10164-12:1994 

Informational 

(Approved) 

NPC 

SAB 

General  Open  Architecture  (GOA)  Framework 

AS  4493 

(Committee  AS- 5) 

Informational 

(Approved) 

lliisJi 

11118 

liBMS 

ILJS 

3 .8.8.1. 2  Alternative  specifications.  The  following  specifications  for  network  fault  reporting  are 
available: 

a.  Banyon  Systems's  Network  Event  Logger  (originally  developed  by  Wang 
Laboratories),  on  which  OSFs  DME  event  services  and  logging  services  are  based. 

b.  Gradient  Technologies:  PC  Event  system  integrated  with  a  Banyon  Systems-based 
Network  Event  Logger  PC  library  and  a  PC  Ally  server  on  which  OSF  has  based 
its  PC  event  and  logging  component. 

3.8.8. 1.3  Standards  deficiencies.  The  present  ISO  10164-4,  "Alarm  Reporting  Function," 
10164-6,  "Log  Control  Function,"  10164-5,  "Event  Report  Management  Function,"  10164-12, 
"Test  Management  Function,"  and  10164-14,  "Confidence  and  Diagnostic  Testing  Service" 
standards  were  designed  with  network  configuration  in  mind.  Theoretically,  these  standards 
should  be  able  to  be  used  for  configuration  management  of  any  computer  system.  Little  work  has 
been  done  in  this  area,  either  in  standards  groups  or  in  products.  Therefore,  exactly  how  these 
standards  should  be  used  in  host  management  is  undetermined. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  and  fault  management  of  network  resources  are  planned,  few  are  available  or 
sufficiendy  complete.  For  example,  these  library  specifications  have  incomplete  object  definitions 
for  modems,  OSI  routers,  and  transport  connections.  Based  on  U.S.  Federal  Government  needs 
(as  shown  by  NIST  surveys),  the  GNMP  added  more  object  class  specifications  and  definitions. 
These  include  the  following  objects:  LANs,  X.25  Wide- Area-Networks  (WANs),  Integrated 
Services  Digital  Network  (ISDN),  Fiber  Distributed  Data  Interface  (FDDI),  modems,  bridges, 
links,  and  a  rudimentary  capability  to  manage  OSI  routers  and  transport  connections. 
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Phase  2  GNMP  objects  also  will  include  protocol  software  (layers  3-7),  routers,  terminal  servers, 
Message  Transfer  Agents  (MTAs),  Private  Branch  Exchange  (PBXs),  and  circuit  switches. 

Versions  1.0  and  2.0  of  the  GNMP  currently  specify  only  network  management  capabilities.  Not 
until  Version  3.0  will  the  GNMP  specify  the  management  information  required  for  general  system 
management,  such  as  host  computer  configuration  and  management,  operating  systems,  and 
database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CMIS/CMIP  for  the 
communications  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for 
the  GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP  also. 
One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 

Fault  management  should  make  use  of  general  event  management  such  as  OSF  DME  event 
services,  but  most  products  currently  implement  their  own  event  management  facilities. 

Finally,  standards  are  needed  for  problem  reporting  and  tracking,  diagnostic  standards  for 
hardware  and  software,  and  fault  isolation. 

3.8.8. 1.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.8.8.1.5  Related  standards.  The  following  standards  are  related  to  fault  management  or  fault 
management  standards: 

a.  ISO/IEC  7498-4: 1989:  Management  Framework. 

b.  ISO/IEC  8571:1988:  File  Transfer,  Access,  and  Management  (FTAM),  as 
specified  in  GOSIP  Version  2  Sections  4, 2.7, 2  and  5.3.1,  if  File  transfer,  Access, 
and  Management  functionality  are  required. 

c.  ISO/IEC  8650: 1 988:  Association  Control  Service  Element  (ACSE),  as  specified  in 
GOSIP  Version  2,  Section  4.2.7. 1,  as  modified  by  the  NMSIG  agreements  in  Part 
18  of  the  OIW  Implementors  Agreements. 

d.  ISO/IEC  8824:1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

e.  iSO/EEC  8825:1990:  Specification  of  Basic  Encoding  Rules  for  ASN.l. 

f.  ISO/IEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7 .2  and  5.3. 1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  Remote  Operations  Service  Element  (ROSE),  as  specified  in 
the  Remote  Operations  Part  1 :  Model  Notation  and  Service  Definition  (ROSES), 
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and  the  Remote  Operations  Part  2:  Protocol  Specification  (ROSBP),  and  as 
modified  by  the  NMSIG  agreements  clause  6.5. 

h.  ISO/IEC  9595:1991:  Common  Management  Information  Service  (CMIS). 

L  ISO/IEC  9596:1991:  Common  Management  Information  Protocol  (CMIP). 

j.  ISO/IEC  10165-1:1993:  Structure  of  Management  Information  (SMI). 

k.  ISO/IEC  10 165-2: 1992:  Definition  of  Management  Information  (DMI). 

l.  ISO/IEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISO/IEC  DIS  1 1578.2:  Remote  Procedure  Call. 

n.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

o.  IEEE  1224: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1155:  Structure  and  Identification  of  Management  Information  for 
Internets  based  on  TCP/IP. 

s.  Internet  RFC  1 157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object  Management). 

3.8.8.1.6  Recommendations.  To  build  or  procure  fault  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  within  the  ISO  10164  and  10165  standards  related  to 
these  requirements.  Finally,  they  must  specify  the  requirements  and  the  related  standards  in  the 
RFP. 
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The  OMNTPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
Version  3.0  of  the  NIST  Application  Portability  Profile. 
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3-8.S.2  Core  dump.  Core  dump  APIs  allow  the  process  to  specify  the  location  where  the  core 
dump  file  is  written.  Many  times  as  a  last  resort  a  core  dump  may  be  initiated  at  termination. 
This  is  useful  as  a  debug  aid.  This  API  allows  an  analyst  to  find  the  core  file  and  post  process  it. 

3.&8.2.1  Standards.  Table  3.8-61  presents  standards  for  core  dumps. 


TABLE  3,8-61  Core  dump  standards 


3.8.8.2 2  Alternative  specification.  There  are  no  alternative  specifications. 
3.8.8.2  .3  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3.8.8.2.4  Portability  caveats.  Portability  problems  are  unknown. 

3.5.8.2.5  Related  standards.  There  are  no  standards  related  to  core  dumps. 

3.8.8.2.6  Recommendations.  There  are  no  adopted  standards  to  recommend. 
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3.8.8J  Hardware  error  and  event  conditions.  (This  BSA  appears  in  both  part  8  and  part  9.) 

An  event  is  an  unsolicited  communication  from  a  hardware  device  to  a  computer  operating 
system,  application,  or  driver.  Events  are  generally  attention-getting  messages,  allowing  a 
process  to  know  when  a  task  is  complete  or  when  an  external  event  occurs.  Error  conditions 
(e.g.,  system  failures,  unauthorized  access  attempts,  or  strange  glitches)  must  be  detected  and 
reported  so  corrective  action  can  be  taken  to  minimize  system  or  network  problems.  (See  the 
BSA  on  error  and  event  logging  for  mote  information  on  tracking  errors.) 

Offline  diagnosis  of  events  which  have  been  written  in  encoded  form  to  the  system  log  is  termed 
event  classification.  Encoded  events  which  are  written  to  the  system  log  for  later  analysis  form 
the  raw  material  for  algorithms  designed  to  diagnose  and  passivate  faults,  that  is  to  prevent  them 
from  being  reactivated.  Offline  classification  of  errors  or  events  which  are  indicative  of  the 
potential  failure  of  a  component  can  be  conducted  only  when  the  required  information  has  been 
saved.  Algorithms  designed  to  improve  system  maintenance  and  to  shorten  the  duration  of 
outages  generally  scan  the  system  event  log  for  patterns  of  event  types.  Such  algorithms  can  be 
used  to  predict  imminent  failure  of  software  or  hardware  components.  This  analysis  of  logged 
events  could  also  be  processed  in  parallel  while  the  main  system  continues  to  perform. 

Services  for  the  detection  of  events  come  in  two  basic  forms:  aedve  and  passive.  Events  come  in 
two  types,  those  which  are  anomalous  and  those  which  are  not  Anomalous  events  may  be 
classified  into  two  categories:  errors,  and  events  which  are  indicative  of  a  fault  which  is  not  yet 
producing  errors,  but  is  the  cause  of  some  degradation  in  system  performance.  P1003.1h  is 
already  addressing  passive  errors  in  their  draft  standard. 

3.8.8.3.1  Standards.  Table  3.8-62  presents  standards  for  hardware  error  and  event  conditions. 


TABLE  3.8-62  Hardware  error  and  event  conditions  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status  ! 
DoD 

(Lifecycle) 

IPC 

iso/mc 

Portable  Operating  System  Interface  (POSEX)  Part  1 : 
System  API  (Replaces  ISO  9945- 1:1990  and  incorporates 
IEEE  1003.1b.  1003.1c.  and  1003.  li) 

9945-1:1996 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface  Definitions, 
Version  2,  Issue  5 

C605  {2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Spedfictlion,  System  Interfaces  and  Headers, 
Version  2,  Issue  S 

C606  (2/97) 

Emerging 

(Approved) 

NPC 

IEEE 

Portable  Operating  System  Interface  (POSIX)  -  Pait  J : 
System  Application  Program  Interface  (API)  Amendment 

1 :  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  I :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  |C  Language! 

1003.  li:  1995 

Informational 

(Approved) 

GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  -  System 
Application  Program  Interface/  C  Language  (adopts 
ISO/IEC  9945. 1:1990) 

FIPS  PUB  151- 
2:1993 

Informational 

(Approved) 

WC 

IEEE 

i  in 

mmrnmmmsmmmiMmmm, 

P100J.U 
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Standard 


Standard 

Reference 


Standard 

Type 


Status 

DoD 

(Lifecycle) 


3.8.S.3.2  Alternative  specification.  The  OSFs  OSF/1  (product  implementation)  is  also  available. 

3.8.8.3J  Standard  deficiencies.  POSIX.l  has  limited  error  and  event  condition  capabilities.  To 
address  this  deficiency,  P1003.  lh  is  including  event  detection.  Active  event  detection  consists  of 
functions  which  request  information  on  the  occurrence  of  events  that  may  not  normally  be 
reported  to  an  application.  Passive  event  detection  occurs  when  other  applications  or  the 
underlying  system  services  provide  event  signaling  to  an  application.  Events  to  be  detected 
include: 


-•  Software  and  Hardware  errors  during  operation, 

--  Processes  that  failed  or  almost  failed  to  meet  scheduled  deadlines, 

-  Times  when  the  system  operated  in  extreme  environmental  conditions, 

--  Errors  reported  during  startup  self-testing  and, 

-  Attempts  to  violate  the  security  policy  of  the  system 

Upon  the  detection  of  an  error  the  operating  system  may  raise  an  exception,  signal  an  exception, 
abort  a  process,  or  take  other  actions.  The  action  taken  by  the  operating  system  depends  on  the 
level  of  severity  of  the  error.  These  actions  include  the  collection  of  relevant  parts  of  the  system 
state,  and  the  encoding  of  events  for  logging  and  notification  by  operating  system  services. 

3.8.8.3.4  Portability  caveats.  Symbolic  error  numbers  are  a  set  of  names  defined  for  error 
numbers  set  by  the  "exec"  functions  to  indicate  the  nature  of  an  error  condition  that  has  occurred. 
Symbolic  error  numbers  have  been  around  for  a  long  time  and  are  reasonably  stable.  However, 
many  implementations,  especially  the  newer  ones,  use  symbolic  error  numbers  that  are  different 
from  one  another.  Applications  using  such  new,  different  symbolic  error  numbers  are  not  portable 
except  to  implementations  using  the  same  error  number  set. 

POSIX,  X/Open,  and  SVID  support  many  of  the  same  symbolic  error  numbers,  with  some 
exceptions.  For  example,  POSIX  does  not  support  the  error  symbols  "EIDRM"  (indicating  an 
identifier  has  been  removed  from  the  system),  "ENOMSG"  (required  message  not  in  the  message 
queue),  and  "ETXTBSY"  (attempt  to  overwrite  active  procedure),  even  though  X/Open,  and 
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SVID  support  them.  Other  differences  in  symbolic  error  numbers  occur  in  the  following  error 
symbols:  "EBADMSG,"  "ENOSR,"  "ENOSTR,"  "EPROTO,"  "ERESTART,"  and  "ETIME." 

Symbolic  error  numbers  provide  portability  only  if  programmers  and  vendors  implement  programs 
using  them.  Implementations  using  numeric  numbers  instead  of  symbolic  error  names  and 
numbers  are  not  portable. 

POSDC,  XyOpen,  and  SVID  allow  additional  implementation-defined  symbolic  error  names  to  be 
created.  Such  implementation-defined  symbolic  error  numbers  may  be  a  necessity  for  a  particular 
application.  These  values  are  usually  returned  by  extended  functionality,  not  defined  by  POSIX.  1. 
The  SVID,  for  example,  defines  the  symbolic  errors  "EBADMSG",  "ENOSR",  and  "ENOSTR" 
which  are  returned  by  the  kemal  "STREAMS"  subsystem.  These  new  symbolic  error  numbers 
should  be  portable  among  all  systems  which  provide  the  underlying  functionality.  The  longest  of 
the  symbolic  error  number  names  is  "ENAMETOOLONG," 

X/Open's  Single  Unix  Specification  (Spec  1 170)  has  aligned  XPG4  with  POSIX  in  the  areas 
where  they  overlap.  Thus  any  XPG4  or  Single  Unix  conforming  system  is  guaranteed  to  respond 
with  the  same  symbolic  error  value  although,  as  discussed  above,  the  actual  error  number  may 
vary. 

3.S.8.3 £  Related  standards.  The  following  standards  are  related  to  hardware  error  conditions: 

a.  IEEE  1003.2: 1992:  POSIX  -  Shell  and  Utility  Application  Interface. 

b.  IEEE  R1003.5: 1992:  Ada  Language  Binding  for  POSIX  (under  revision). 

c.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

d.  IEEE  P1387.1:  POSIX  System  Administration  -  Part  1:  Overview. 

e.  IEEE  1387.2:1995:  POSIX  System  Administration  -  Part  2:  Software. 

f.  IEEE  P1387.3:  POSIX  System  Administration  -  Part  3:  User  and  Group 
Administration. 

g.  IEEE  P1003.  lg:  Protocol  Independent  Interfaces. 

h.  IEEE  1224.2:1993:  Directory  Services  API  -  Language  Independent. 

i.  IEEE  1224. 1:1993:  X.400  Based  Electronic  Messaging  API. 

j.  IEEE  P  1238.1:  OSI  Applications  Program  Interface  -  FTAM, 

k.  IEEE  P 1 35 1 :  OSI  Application  Interfaces  -  ACSE. 


April  7,  1997 


3.8-142 


Version  3.1 


Information  Technology  Standards  Guidance 


Operating  System  Services 


3.8,8.3.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:  1995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in  the  new 
ISOAEC  9945-1:1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should  also  be 
consulted.  It  adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996  version.  IEEE  1003.  lb 
added  asynchronous  event  notification  to  the  original  IEEE  1003.1.  FIPS  151-2  specifies  the 
read/write  return  options.  SUS  supports  additional  error  symbols. 

To  get  the  better  event  management  capabilities  needed  for  networking,  communications, 
transaction  processing,  and  real  time  applications,  explicitly  specify  the  IEEE  1003.1b  standard's 
real  time  signals  option  for  asynchronous  event  notification.  For  U.S.  Federal  Government 
procurements,  the  NIST  Application  Portability  Profile  (APP)  and  FIPS  151-2  have  some  special 
file  and  directory  requirements: 

a.  The  APP  and  FIPS  151-2  require  support  for  the  error  message 
"ENAMETOOLONG"  for  the  open  command. 

b.  The  APP  and  FIPS  151-2  require  read()  calls  and  write()  calls  that  are  interrupted 
by  a  signal  after  they  have  successfully  read  or  written  data  shall  return  the  number 
of  bytes  the  system  has  read.  POSIX  allows  the  return  of  either  the  number  of 
bytes  read  or  written  or  a  return  of  -1  with  "ermo"  set  to  [EINTR]  after  a 
successful  read  or  write. 

To  get  greater  functionality  than  POSIX  provides,  establish  the  error  management  interfaces 
provided  by  X/Open  as  an  internal  standard.  The  problem  is  that  in  implementations  compliant 
with  POSIX,  many  specific  system  calls  have  differences  in  their  error  messages  and  exception 
management  handling.  These  system  call  commands  must  be  analyzed  to  see  which  enror 
messages  to  specify  for  certain  critical  commands,  as  the  NIST  did  in  developing  FIPS  151-1.  A 
second  problem  occurs  because  X/Open,  the  SVID,  and  OSF  specify  more  functionalities  than 
POSIX.  Even  where  these  functionalities  are  the  same,  X/Open's,  the  SVID's,  and  OSF/l's  error 
messages  are  often  different  In  general,  X/Open's  error  messages  for  specific  system  calls  tend  to 
be  the  same,  but  they  differ  from  OSF/l's,  which  is  the  same  as  Berkeley  UNIX's. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding:  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3JL8.4  State  collection.  Before  diagnosis  can  occur,  the  relevant  parts  of  the  state  of  a  system 
must  be  preserved.  In  those  cases  where  the  operating  system  returns  control  to  an  application 
after  the  occurrence  of  an  error,  the  application  must  decide  what  action  to  take.  One  possible 
action  is  a  dump  of  the  process  state  to  memory  or  stable  storage.  In  those  cases  where  the 
operating  system  retains  control  after  an  error  is  detected  the  operating  system  may  save  parts  of 
the  system  state  for  later  analysis. 

For  those  detected  events  which  are  classified  as  anomalous,  an  application  may  wish  to 
communicate  its  interest  to  the  operating  system  in  the  event  by  means  of  registering  for  and 
specifying  the  extent  of  the  state  collection  required.  The  parts  of  the  state  preserved  are 
application  specific.  The  checkpointing  of  a  process  is  an  example  of  a  fault  tolerance  method 
which  requires  the  process  state  be  saved.  Parts  of  the  process  state  which  are  candidates  for 
preservation  (as  determined  by  the  application)  examples  are  process  memory,  process  data 
segments,  process  stacks,  process  states,  process  status,  program  counters,  pointers  and  contents 
of  the  all  CPU  registers. 

3. 8.8.4. 1  Standards.  Table  3.8-63  presents  standards  for  state  collection. 


TABLE  3.8-63  State  collection  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

»c 

1— gl  1 

o£2£. 

3.8.8.4.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.8.4.3  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3.8.8.4.4  Portability  caveats.  Portability  problems  are  unknown. 

3.8.8.4.5  Related  standards.  There  are  no  standards  related  to  state  collection. 

3.8.8.4.6  Recommendations.  There  are  no  adopted  standards  to  recommend  at  this  time. 
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3JUi£  Error  recovery  ait  ’  reconfiguration.  There  are  two  main  types  of  corrective  actions  to 
take  when  error  conditions  are  detected.  Error  recovery  occurs  while  the  system  is  operational, 
while  reconfiguration  may  occur  when  the  system  is  operational  or  while  it  is  inoperable. 

Error  recovery  methods  are  based  on  hardware  redundancy,  information  redundancy  and  a 
combination  of  the  two  (hybrid  redundancy  methods).  These  methods  include  N  modular 
redundancy  with  voters,  error  detection  /  correction  codes,  and  combinations  of  the  two.  Another 
type  of  error  recovery  is  temporal  redundancy.  A  technique  which  is  classified  under  this 
category  is  retry.  Forward  and  backward  recovery  in  real-time  systems  is  classified  as  a  hybrid 
method.  Backward  recovery  generally  involves  saving  the  state  of  a  process  at  intervals,  so  that 
the  process  may  be  restarted  at  a  point  at  which  its  state  is  valid. 

System  reconfiguration  is  a  means  of  providing  or  improving  the  fault  tolerance  of  a  system. 

When  a  faulty  component  which  has  been  causing  errors  to  occur  is  isolated  and  switched  offline, 
a  reconfiguration  has  occurred.  In  some  systems,  it  is  not  possible  to  repair  a  component.  In 
these  systems  the  fault  tolerance  characteristics  are  permanently  degraded,  whenever  a  component 
is  removed  from  operation.  For  systems  which  contain  redundant  reparable  components,  the  fault 
tolerance  characteristics  of  the  system  are  temporarily  degraded. 

3.8.8.5.1  Standards.  Table  3.8-64  presents  standards  for  error  recovery  and  reconfiguration. 


TABLE  3.8-64  Error  recovery  and  reconfiguration  standards 


Standard 

Sponsor 

Standard 

Standard 

Status  1 

Type 

Reference 

(Lifecycle)  I 

m 

Piwo-ui 

1 

3.8.8.5.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.8.5.3  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3.8.8.5.4  Portability  caveats.  Portability  problems  are  unknown. 

3.8.8.5.5  Related  standards.  There  are  no  standards  related  to  error  recovery  and 
reconfiguration. 

3.8.8.5.6  Recommendations.  There  are  no  adopted  standards  to  recommend  at  this  time. 
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3.8J1.6  Diagnosis.  Diagnosis  of  events  entails  analysis  of  the  state  of  the  system  this  is  where 
each  indiviual  fault  management  application  can  build  in  their  unique  intelligence  and  knowledge 
of  the  system.  This  may  be  performed  online  or  offline.  In  some  cases  an  event  may  be  encoded 
so  that  the  operating  system  can  take  immediate  action  to  deal  with  an  event,  a  process  can 
register  for  notification  upon  the  occurance  of  an  event  while  in  others  the  diagnosis  may  take 
place  offline.  All  but  the  most  severe  error  conditions  are  usually  written  in  an  encoded  form  into 
the  system  log.  In  some  cases  these  events  will  also  generate  a  notification  message  to  system 
management  control. 

Diagnosis  occurs  in  error  recovery  though  a  variety  of  mechanisms.  In  an  N -modular  redundancy 
enor  recovery  scheme,  diagnosis  can  be  performed  in  real-time.  It  occurs  when  the  voter(s) 
detect  an  inconsistency  in  the  output  of  N  hardware  modules.  In  this  case  an  error  is  detected  and 
recovery  initiated  when  the  output  from  one  (or  possibly  more)  modules  is  discarded.  In  more 
elaborate  schemes,  the  system  will  then  initiate  fault  diagnosis  on  the  apparently  faulty 
component. 

Offline  diagnosis  of  events  which  have  been  written  it;  encoded  form  to  the  system  iog  is  termed 
event  classification. 

3. 8.8.6. 1  Standards.  Table  3.8-63  presents  standards  for  diagnosis. 


TABLE  3.8-65  Diagnosis  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

‘§M . 

wi  -Mm* 

mu.ik 

3.8.8.6.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.S.8.6  .3  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3.8.8.6.4  Portability  caveats.  Portability  problems  are  unknown. 

3.8.8.6.5  Related  standards.  There  are  no  standards  related  to  diagnosis. 

3.8.5.6.6  Recommendations.  There  are  no  adopted  standards  to  recommend  at  this  time. 
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3X8.7  SUutdown/Reboot  services.  The  intent  of  these  APIs  is  to  provide  a  means  of  recovering 
a  system  by  brute  force  reinitialization.  The  same  APIs  can  be  used  to  completely  disable  a 
system  which  is  deemed  to  be  faulty  in  some  manner. 

3XX7.1  Standards.  Table  3.8-66  presents  standards  for  shutdown/reboot 


TABLE  3X66  Shutdown/Reboot  services  standards 


Standard  Sponsor  Standard 

Type 

Standard 

Reference 

m 

1 '  ’ 

i 

3X8.7.2  Alternative  specification.  There  are  no  alternative  specifications. 

3X8.7 3  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3X8.7.4  Portability  caveats.  Portability  problems  are  unknown. 

3X8.7.5  Related  standards.  There  are  no  standards  related  to  shutdown/reboot  services. 

3X8.7.6  Recommendations.  More  work  is  needed  to  fully  define  these  APIs.  There  is  some 
interest  in  interfaces  to  enable  orderly  system  startup  and  shutdown. 
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3-8.8JI  Process  and  event  trace  services.  The  trace  work  within  the  SRASS  Project 
Authorization  Request  (PAR)  has  enjoyed  the  combined  efforts  of  the  SRASS  working  group  and 
the  Realtime  working  group.  Trace  is  important  to  both  groups  because  it  allows  the  developer 
of  applications  to  build  a  reliable  system  and  it  allows  the  application  writer  to  tell  what  processes 
are  doing  without  substantially  affecting  the  intended  behavior.  This  is  important  in  realtime 
systems  since  it  is  not  invasive  and  does  not  affect  critical  timing  and  it  is  important  to  reliable 
systems  since  it  can  be  used  to  determine  reliability  problems.  Trace  points  can  be  coded  and 
inserted  into  the  application  program  code  with  specific  triggers  which  when  activated  put  events 
of  interest  quickly  into  a  trace  buffer.  This  information  can  be  used  later  with  the  aid  of 
automated  tools  to  help  in  the  analysis  of  performance  problems,  behavior  problems,  detect 
programming  mistakes,  or  process  timing  mismatches  and  randomly  exceeded  time  budgets. 

Tracing  should  be  distinguished  from  on-line  debugging  in  which  no  special  programmatic 
changes  are  required  in  the  program,  and  in  which  analysis  is  done  at  the  time  the  events  of 
interest  happen,  and  from  logging,  in  which  the  events  of  interest  can  be  processed  by  other 
programs,  possibly  in  realtime. 

3.8.8.8.1  Standards.  Table  3.8-67  presents  standards  for  process  and  event  trace. 


TABLE  3.8-67  Process  and  event  trace  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

M 

' 

•  •  8$ . SSSfeSSK 

BiHi 

3. 8.8. 8.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.8.8J  Standard  deficiencies.  Standard  deficiencies  are  unknown. 

3.8.8.8.4  Portability  caveats.  Portability  problems  are  unknown. 

3.5.8.8.5  Related  standards.  There  are  no  standards  related  to  trace  services. 

3.8.8.8.6  Recommendations.  There  are  no  adopted  standards  to  recommend  at  this  time. 
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3.8.8.9  Built-in  Test .  Built-in  Test  (BIT)  is  a  fault  management  function  that  provides  a 
capability  to  access  unique  hardware  configurations  supporting  the  built-in  test  functions  for 
operational  status  of  computer  components. 

3.8.8. 9.1  Standard.  Table  3.8-68  presents  standards  for  built-in  test 


TABLE  3.8-68  Built-in  Test  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

.  «" 

ME 

111 

warn 

3.5.8.9.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.8.9.3  Standard  deficiencies.  ARD  50067  is  domain  specific  -  oriented  toward  support  of 
avionics  applications. 

3.8.8.9.4  Portability  caveats.  Portability  problems  arc  unknown  because  of  the  immaturity  of  the 
specification. 

3.8.5.9.5  Related  standards.  There  are  no  standards  related  to  built-in  test. 

3.8.8.9.6  Recommendations.  There  is  no  approved  standard  available  to  recommend  at  this  time. 
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3.8.9  Clock/calendar  services.  These  are  services  for  maintaining  and  synchronizing  system 
clocks  and  triggering  events  based  on  the  passage  of  time. 


3.8.9. 1  Clocks  and  timers.  A  clock  is  a  mechanis  m  for  measuring  the  passage  of  time  and 
maintaining  the  system  time.  Timers  are  used  to  start  or  stop  processes  based  on  the  passage  of  a 
specific  amount  of  time.  A  timer  can  work  together  with  a  clock  by  sending  a  start  or  expiration 
signal  when  an  associated  clock  reaches  or  exceeds  a  specified  time. 

3.8.9.1.1  Standards.  Table  3.8-69  presents  standards  for  clocks  and  timers. 


TABLE  3.8-69  Clocks  and  timers  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  Syrtero  inferfK*  (POSQC)  Put  l: 

Sy item  API  (Repiece*  ISO  9945- 1 : 1990  end  incorporate! 
IEEE  1003.1b,  1003.1c.  end  1003.1i) 

9945-1:1996 

Mandated 

(Approved) 

NPC 

TRKK 

Portable  Operating  Syitem  Interface  (POSIX)  •  Pert  1 : 
Syrtan  Application  Program  Interface  (API)  Amendment 

1 :  Realtime  Extension  (C  Wantage) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

rppp 

POSIX  Pert  1 :  Syitem  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Reel  Time 
Extension  1C  Language) 

1003.  li:  1995 

Informational 

(Approved) 

3.8.9.1.2  Alternative  specifications.  The  following  specification  is  available: 

a.  SAE  ARD  50067  Draft:  Avionics  Operating  Syste:..  API  Requirements. 


3.8.9. Standards  deficiencies.  Deficiencies  in  the  existing  standard  are  unknown. 


3.8.9. 1.4  Portability  caveats. 


3.8.9. 1.5  Related  standards.  There  are  no  related  standards. 


3.8.9.1.6  Recommendations.  ISO/TEC  9945-1:1996  is  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/1EC  9945-1:1990.  IEEE  1003. lb:  1993, 
IEEE  1003. lc:  1 995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996. 
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3.8.9.2  Real  time  timers.  Real  time  timers  ate  high  resolution  timers  that  allow  for  fixed, 
periodic,  offset,  absolute,  and  relat,  ~  schedules,  and  track  elapsed  time  very  accurately  to 
support  the  highest  priority  processes  and  event  notifications  in  real  time  applications.  They  also 
may  provide  timing  signals  for  timesharing  operations. 

3.8.9.2.1  Standards.  Table  3.8-70  presents  standards  for  real  time  timers. 


TABLE  3.8-70  Real  time  timers  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Put  1: 
System  API  (Replaces  ISO  9943-1 : 1990  end  incorporates 
EKE  1003.1b.  1003.1c.  end  1003.1H 

9945-1:1996 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interface  Defiritions, 
Version  2,  Issue  S 

C605  (2/97) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification,  System  Interfaces  and  Headers, 
Vonion  2,  Issue  5 

C606  (2/97) 

Emerging 

(Approved) 

NPC 

TFPF 

Portable  Operating  System  Interface  (POSIX)  •  Part  1: 
System  Application  Program  Interface  (API)  Amendment 

1 :  Realtime  Extension  (C  lancuace) 

1003.1b:1993 

Informational 

(Approved) 

NPC 

TFPF 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  (C  Language) 

1003.11: 1995 

Informational 

(Approved) 
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3.8.9.2.2  Alternative  specifications.  The  following  specification  is  also  available: 
a.  Berkeley  4.2/4.3  Unix. 

3.5.9.2.3  Standards  deficiencies.  POSIX. lb  timer  facilities  lack  the  Berkeley  Unix  virtual  and 
profiling  interval  time  functions.  The  POSIX. lb  real  time  timer  service,  with  its  requirement  for 
nanosecond  resolution  timers,  is  better  suited  for  real  time  applications  than  industry  standards. 
For  example,  the  granularity  of  ISO/1EC  9945- 1  timer  functions  (seconds),  Berkeley  Unix 
(seconds  and  microseconds)  the  SVID  Issue  4  (microseconds),  and  System  V  Release  4 
(microseconds)  is  not  sufficient  for  critical  real  time  applications.  Also,  some  real  time 
applications  need  to  have  more  than  one  outstanding  time  interval  on  the  same  time  base 
(clockjd)  to  trigger  different  functions.  Berkeley  Unix,  1SO/IEC  9945- 1 : 1 990,  and  System  V 
Release  4  do  not  allow  this. 
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3A9.2.4  Portability  caveata.  System  V  Release  4  and  Berkeley  Unix  timers  are  identical  to  each 
other.  They  are  not  compatible  with  POSIX.  1  b  timer  functions  however,  because  they  use  signals 
not  existing  in  POSIX.  lb. 


The  Berkeley  Unix  "adjtime"  function  has  no  POSIX.lb  equivalent 

Berkeley  Unix  does  not  provide  programmatic  calls  to  obtain  a  timer's  resolution  or  support  the 
ability  to  request  "absolute"  timer  expirations. 

3JI.9.2.5  Related  standards.  The  following  standards  are  related  to  real  time  timer  standards: 
a.  None. 


3.8.9.2.6  Recommendations.  The  following  wording  is  recommended  for  specifying  real  time 
timers: 


"Real  time  systems  offered  as  a  result  of  the  requirements  of  which  this  is  a  part  shall  conform  to 
the  timer  requirements  established  by  the  IEEE  1003.1b  standard  incorporated  into  ISO/IEC 
9943-1:1996  and  shall  implement  nanosecond  resolution  timers  and  all  of  the  timer  functions 
specified  in  the  1003.  lb  standard,  as  well  as  the  additional  real  time  features  specified  elsewhere 
in  this  document" 

POSIX.  lb  timer  calls  can  be  mapped  to  System  V  timer  functions.  Examples  of  how  to  do  this 
are  published  in  draft  12  of  the  IEEE  P1003.1b  standard. 

The  POSIX.lb  time  functions  can  be  mapped  to  the  Berkeley  time  functions,  although  not  with 
the  POSIX.  1  b  nanosecond  resolution  for  the  timers.  The  mapping  is  shown  in  draft  1 2  of  the 
POSDC. lb  standard. 

The  Berkeley  Unix  "adjtime()''  function  can  be  implemented  as  a  library  function  on  top  of  the 
POSIX.lb  "clock_setdrift()"  function. 

Berkeley  Unix's  virtual  and  profiling  interval  timing  functions  can  be  implemented  as  extensions 
using  new  clock Jd  values. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POS1X.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3.S.9.3  Distributed  timing  service.  (This  BSA  appears  in  part  8  and  part  1 1.)  Distributed 
timing  service  (DTS)  guarantees  synchronization  among  all  system  clocks  in  a  distributed 
network.  Synchronized  timing  is  necessary  to  maintain  scheduling  of  activities  and  sequencing  of 
events.  DTS  uses  RPC  in  the  communications  between  DTS  clients  and  DTS  servers.  It  also 
uses  RPC  in  the  protocol  between  a  Time  Server  and  a  Time  Provider.  Since  DTS  is  based  on 
DCE  RPC,  which  uses  DCE  Threads,  DTS  also  uses  Threads.  DTS  depends  on  CDS  to  fid 
Time  Servers  and  their  locations.  GDS  may  be  used  indirectly  if  a  Global  Time  Server  is 
registered  in  a  foreign  cell  registered  in  the  X.500  namespace.  DTS  uses  the  DCE  Security 
Service  to  authenticate  its  interactions. 

3.8.9.3.1  Standards.  Table  3.8-7 1  presents  standards  for  distributed  timing  service. 


TABLE  3.8-71  Distributed  timing  service  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Distributed 
Time  Service  (DTS) 

DCE  1.1 

DTS:  1994 

Mendeted 

(Approved) 

CPC 

IETF 

Network  Tune  Protocol  (V3) 

RFC  1305:1992 

Mandeted 

(Approved) 

CPC 

X/Open 

X/Oprfi  DCE:  Tune  Services 

C310(ll/94) 

Informational 

(Approved) 

IIb 

8S8 

I 

3.8.9.3.2  Alternative  specifications.  The  following  specification  is  available: 

a.  SAE  ARD  50067  Draft:  Avionics  Operating  System  API  Requirements. 

3.8.9.323  Standards  deficiencies.  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003.1b 
contains  time  services  related  to  high  resolution  real  time  timers,  but  internationalization  and 
highly  functional,  system-wide  clocks  are  beyond  its  scope.  The  IEEE  P1003.1j  draft  standard 
extends  the  model  of  1003.  lb  Clocks  and  Timers  to  include  access  to  a  monotonic  clock  and  a 
synchronized  clock;  however,  like  1003.  lb,  the  actual  implementation  of  these  clocks  is  beyond 
the  scope  of  the  standard. 

To  date,  there  is  no  standardized  API  for  the  management  of  distributed  time  services.  However, 
the  IEEE  P1003.2 1  working  group  intends  to  develop  an  API  for  time  management  serices,  which 
would  include  such  time  management  protocols  as  NTP  and  DTS. 

3.8.9.3.4  Portability  caveats.  If  the  time  services  are  to  be  used  in  building  internationalized 
programs,  portability  is  unlikely.  Behavior  is  not  portable  across  systems  in  which  one  supports 
the  nanosecond-resolution  timers  specified  by  the  SVID  and  Berkeley  Unix.  However,  the  IEEE 
P1003,  lj  draft  standard  provides  applications  with  explicit  access  to  a  synchronized  clock, 
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utilizing  the  portable  standard  interfaces  provided  in  IEEE  1003.  lb  (incorporated  in 
ISO  9945-1:1996). 

When  several  applications  are  executed  simultaneously,  problems  may  occur  when  remote 
application  components  are  out  of  time  synchronization  with  each  other.  DCE  takes  care  of  this 
by  synchronizing  all  the  host  clocks  on  the  system  through  its  DTS. 

One  component  of  die  DTS  clerk  reads  the  clocks  for  a  certain  time  interval  on  each  of  the  host 
machines  through  software  called  the  DTS  server.  The  DTS  clerk  then  computes  the  midpoint 
between  all  the  time  intervals  to  determine  a  new  average  time  and  resets  the  clocks  of  each  host 
The  DTS  also  can  read  time  from  an  outside  source,  such  as  the  Universal  Coordinated  Time 
Standard  through  a  telephone  or  radio,  then  set  host  clocks  to  this  time. 

3.8.9.3.5  Related  standards.  IEEE  1003.1b  is  related  to  this  service. 

3.8.9.3.6  Recommendations.  Procurements  should  use  the  time  services  corresponding  to  the 
operating  system  being  specified  in  the  procurement.  OSF  DCE  Timing  should  be  specified  for 
distributed  systems. 
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3 .8.9.4  Year  2000  problem/fixes.  For  years  programmers  have  stored  date  information  in 
"mm/dd/yy"  format  to  conserve  space  in  disk  storage  and  computer  memory.  They  adjusted 
computations  to  take  the  two-digit  year  into  consideration  when  computing  time  periods,  ending 
dates,  etc.  Calculations  based  on  the  year  value  in  its  two  digit  format  are  likely  to  yield 
unspecified  results  once  the  value  rolls  over  to  "00"  in  the  year  2000.  Semantics  in  operating 
system  commands  have  been  changed  to  allow  for  use  of  a  four  digit  field. 

3.8.9.4.1  Standards.  Table  3.8-72  presents  standards  for  the  Year  2000  problem. 


TABLE  3.8-72  Year  2000  problem/fixes  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle)' 

CPC 

JOOpen 

Single  UNIX  Specification,  Sytfem  Interface*  and  Header*, 
Vernon  2,  Iuue  5 

C606  (2/97) 

Emerging 

(Approved) 

3.8.9.4.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.8.9.43  Standard  deficiencies.  Many  current  standards  are  unable  to  handle  four-digit  year 
codes.  Hardware  will  also  cause  difficulties  for  system  admistrators  and  chief  information 
officers.  System  clocks  on  virtually  every  personal  computer  will  wind  up  with  corrupted  dates 
on  January  1, 2000.  Some  workstations,  minicomputers,  mainframes,  elevators,  and  automobile 
central  computers  will  fall  victim  to  the  problem.  In  most  cases,  software  patches  can  alleviate 
the  problem,  but  in  some  cases,  the  date  issue  can  be  resolved  only  by  replacing  the  hardware. 

3.8.9.4.4  Portability  caveats.  Application  programs  will  have  serious  portability  problems 
moving  among  platforms  with  different  date  structures. 

3.8.9.4.5  Related  standards.  Thei  re  no  standards  related  to  the  Year  2000  problem. 

3.8.9.4.6  Recommendations.  Organizations  must  get  executive  management  to  acknowledge  the 
problem  and  take  serious  action.  According  to  the  March  1996  Computer  Systems  Laboratory 
Bulletin  from  NIST,  the  Federal  Information  Resources  Management  Policy  Council  (FIRMPOC) 
has  a  work  group  in  place  to  identify  issues  and  recommend  actions  concerning  the  Year  2000 
problem.  The  group  provides  agencies  with  a  definition  of  Year  2000  compliance  and  issues  a 
recommendation  on  contract  wording  to  that  effect.  The  Office  of  Management  and  Budget  has 
also  taken  an  active  interest  in  the  Year  2000  problem.  The  Defense  Information  Systems  Agency 
(DISA)  Chief  Information  Officer  (CIO)  will  oversee  DISA's  year  2000  program  while  the  Center 
for  Computer  Systems  Engineering  (CFCSE)  will  be  providing  support  assistance  to  the  DOD. 

Peter  de  Jager,  a  Toronto-based  consultant  has  established  the  Year  2000  Information  Center  on 
the  World  Wide  Web  at  "http://www.year2000.com/".  Links  to  other  articles  and  publications  on 
the  Year  2000  phenomenom  are  available  at  that  site. 
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X/Open  has  addressed  the  Year  2000  problem  and  provided  utilities  to  handle  it  in  the  latest 
release  of  the  Single  Unix  Specification.  X/Open  is  also  drafting  a  White  Paper  on  the  subject  and 
advises  implementors  to  define  %y  such  that  values  in  the  range  €9-99  refer  to  the  twentieth 
century  and  values  in  the  range  00-68  refer  to  the  twenty-first  century.  This  is  consistent  with  the 
touch  command  within  the  X/Open  CAE  specifications.  Programmers  are  adviced  to  use  the  %y 
field  descriptor  which  defines  year  as  a  four  digit  field  (ccyy).  The  latest  version  of  the  X/Open 
CAE  specification  denotes  the  interpretation  of  the  ranges  in  this  advice  to  implementors,  and 
adds  the  %C  specifier  to  the  interface  to  denote  the  century. 

Issue  5  of  the  Single  UNIX  Specification  includes  the  following  changes:  interfaces  previously 
defined  in  the  ISO  POSIX.2  standard;  C  Language  Binding;  Shared  Memory;  the  addition  of 
Threads  and  a  Realtime  Threads  Feature  Group  to  align  with  POSIX;  Multibyte  Support 
Extension  (MSE)  to  align  with  ISO/IEC;  Large  File  Summit  (LFS)  Extensions  for  support  of  64- 
bit  or  larger  files  and  file  systems;  X/Open-specific  Threads  extensions  and  dynamic  linking. 
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3 A 10  Operating  system  object  services.  These  services  define  the  rules  for  creating,  deleting, 
and  managing  objects. 

3.8.10.1  Object  request  broker.  (This  BSA  appears  both  in  part  8  and  in  part  11.)  The  Object 
Request  Broker  (ORB)  provides  a  mechanism  for  accessing  objects  anywhere  in  a  distributed 
computing  environment  It  provides  a  method  for  defining  objects  and  their  interfaces.  In 
operation,  the  ORB  provides  routing,  address  resolution,  and  authentication  services,  as  well  as 
parameter  marshaling  and  conversion  if  necessary. 

3.8.10.1.1  Standards.  Table  3.8-73  presents  standards  for  object  request  brokers. 


TABLE  3.8-73  Object  request  broker  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

OMG 

CORBA  2.0:1995 

Mandated 

(Approved) 

CPC 

X/Opeo 

Common  Object  Roque*  Broker  Arciu  Lecture  aod 
Specification 

C432  (8/94) 

Informational 

(Approved) 

CPC 

X/Open 

Coalmen  Object  Service* ,  Vot  1  &  2 

P432/P502 

Informational 

(Approved) 

CPC 

OMG 

Common  Object  Requeet  Broker  Ardiitectuie  (CORBA) 
Vernon  1.2.  (Seme  u  X/Open  C432) 

CORBA 

Specification  Ver. 
1.2  93-12-43 

Informational 

(Approved) 

CPC 

OSF 

Diitiibuted  Computing  Environment  (DCE) 

DCE  1.1:1994 

Informational 

(Approved) 

or 

** 

H9MS 

ggi 

3.8.10.1.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.8. 10. 1.3  Standards  deficiencies.  At  present,  there  is  no  independent  test  for  conformance  to 
any  version  of  the  CORBA  specification. 

CORBA  1.2  (also  called  CORBA  l.X)  includes  a  standard  Interface  Definition  Language  (IDL) 
for  defining  objects.  The  IDL  is  not  the  same  as  OSF  DCE  Remote  Procedure  Call  IDL,  although 
there  are  similarities.  CORBA  1.2  also  defines  a  standard  API  for  accessing  ORB  servicer,  such 
as  those  needed  to  declare  that  an  object  is  available  for  use,  or  to  access  an  object. 

CORBA  1.2  does  not  include  a  specification  for  interoperability  between  ORB's,  therefore  ORB's 
from  different  vendors  are  likely  to  be  incompatible.  This  is  a  major  feature  of  the  new  CORBA 
2.0.  OMO's  CORBA  2.0  specification  allows  for  two  types  of  RPC  mechanisms:  (1)  a  mandatory 
General  Inter-ORB  Protocol  (GIOP),  and  an  optional  DCE  RPC  protocol.  ORB's  that  use 
different  methods  will  still  not  be  interoperable.  CORBA  2.0  does  not  specify  other  types  of 
distributed  computing  services  (e.g.  remote  procedure  call(RPC),  security,  directory,  time, 
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threads,  file  system,  and  administration).  Therefore,  while  CORBA  2.0  ORBs  will  interoperate, 
higher  level  distributed  services  (security,  directory,  etc.)  may  not 

CORBA  requires  a  "mapping"  of  IDL  into  each  application  programming  language  that  is  used. 
Mappings  exist  for  C,  C++,  and  Smalltalk,  and  an  Ada95  mapping  is  under  development 

3.8.10.1.4  Portability  caveats.  Applications  developed  for  one  ORB  are  likely  to  be  portable  to  a 
different  ORB.  However,  the  lack  of  interoperability  specifications  means  that  an  object 
implemented  on  one  ORB  can  usually  not  be  accessed  from  a  different  ORB.  In  order  to  be 
interoperable,  a  system  must  select  a  single  vendor's  ORB  for  use  across  the  enterprise. 

All  vendor  claims  for  conformance  to  CORBA  2.0  should  be  matched  by  product  demonstrations 
in  the  target  environment  before  final  contract  award  is  made.  If  no  such  demonstration  is  made, 
serious  interoperability  and  security  problems  could  result,  particularly  in  multi-vendor 
environments. 

3.8.10.1.5  Related  standards.  The  following  standards  are  related  to  ORBs  or  their  standards: 

a.  Component  Integration  Laboratories  Inc.  (CILabs):OpenDoc 

b.  Taligent  Inc.iCommonPoint 

c.  Next  Computer  Inc.  :OpenStep 

3.8.10.1.6  Recommendations.  Users  buying  distributed  object  technology  from  multiple  vendors 
must  be  cautious.  The  use  of  ORB  technology  should  be  limited  to  pilot  projects  and  programs 
with  a  limited  number  of  sites.  If  an  ORB  is  used,  the  Object  Management  Group  (OMG) 
CORBA  (Common  Object  Request  Broker  Architecture)  Version  2.0  is  recommended.  The 
vendor  must  provide  a  plan  to  migrate  to  CORBA  2.0  with  the  DCE  RPC  as  soon  as  possible. 

The  vendor  should  also  be  required  to  state  his  proposed  solutions  to  the  other  distributed 
computing  services  listed  above,  and  to  identify  how  these  solutions  relate  to  the  distributed 
computing  services  already  in  the  user's  inventory. 

Because  of  the  lack  of  ORB  interoperability,  OSF  DCE  is  the  preferred  solution  to  distributed 
computing  requirements  in  the  near  term.  OSF  DCE  provides  the  following  distributed 
computing  services:  RPC,  security,  directory,  time,  threads,  file  system,  and  administration. 
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3.8.11  Compound  document  services.  Compound  documents  are  structured  documents 
containing  subdocuments  of  varying  types  of  data  (spreadsheets,  graphics,  text,  etc.)  and  links  to 
other  documents  or  parts  of  other  documents.  Updating  a  document  which  has  been  linked  into 
others  causes  the  linking  documents  to  be  updated  as  nesessary.  Compound  documents  are 
closely  associated  with  "component  software"  technology,  which  allows  for  editing  of  parts  of  the 
compound  document  by  that  editor  best  suited  to  manipulating  the  type  of  data  which  it  contains. 

Although  compound  document  systems  usually  have  a  strong  GUI  requirement,  the  document 
embedding,  linking,  and  storage  functionality  which  are  the  defining  attributes  of  compound 
documents  are  independent  of  the  display  format 

3.8.11.1  Document  linking.  Document  linking  ensures  that  data  stored  in  one  document  and 
required  by  another  (such  as  financial  numbers  in  a  spreadsheet  which  are  required  in  a  year-end 
report)  are  always  up-to-date  in  the  second  by  inserting  into  the  dependent  document  a  pointer  to 
the  original  source  of  the  data,  rather  than  a  copy  of  the  current  value  of  the  data. 

3.8.11.1.1  Standard.  Table  3.8-74  presents  standards  for  document  linking. 


TABLE  3.8-74  Document  linking  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

mm 

HyperText  Markup  Language  (HTML)  v.2.0 

RFC  1866:1995 

Informational 

(Approved) 

Sliilll 

SlSIiii 

■>  S'  s  \ 

qhnmht) 

3.8.11.1.2  Alternative  specification.  The  only  other  specifications  are  proprietary. 

3.8.11.1.3  Standard  deficiencies.  None  known. 

3.8.11.1.4  Portability  caveats.  OpenDoc  is  presently  available  only  on  proprietary  operating 
systems,  but  development  of  a  reference  port  to  Unix  is  ongoing. 

3.8.11.1.5  Related  standards.  The  following  standards  are  related  to  document  linking: 

a.  ISO  8879: 1986  -  Standard  Generalized  Markup  Language  (SGML). 

b.  OMG  Common  Object  Request  Broker  Architecture  (CORBA)  ver  2. 

3.8.1 1.1.6  Recommendations.  There  are  no  approved  standards  to  recommend  at  this  time. 
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1.8.11.2  Document  embedding.  Where  document  linking  creates  links  between  separate 
documents,  document  embedding  collects  data  of  various  types  into  one  document  This  has  the 
advantage  that  moving  the  file  maintains  the  relationships  between  the  contained  data  elements, 
but  it  requires  the  user  to  explicitly  manage  the  consistency  of  data  among  several  different 
copies. 

3.8.1 1.2.1  Standard.  Table  3.8-73  presents  standards  for  document  embedding. 


TABLE  3.8-75  Document  embedding  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

- «3RT 

iw.;y  . ;  T  - 

J-'  "<  J- 

liiESB 

3.8.11.2.2  Alternative  specification.  Microsoft's  proprietary  specification  OLE  provides 
document  embedding.  Fujitsu's  "Fresco"  project  has  been  submitted  to  th  Object  Management 
Group  for  consideration  as  an  OMG  specification. 

3.8.11.2.3  Standard  deficiencies.  N'.ie  known. 

3.8.11.2.4  Portability  caveats.  GpenDoc  is  presently  available  only  on  proprietary  operating 
systems,  but  development  of  a  reference  port  to  Unix  is  ongoing. 

3.8.11.2.5  Related  standards.  None 

3.8.11.2.6  Recommendation*  There  are  no  approved  standards  to  recommend  at  this  time. 
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3.8.1 1-3  Compound  document  editing.  Editing  of  compound  documents  requires  careful 
coordination  to  ensure  that  links  to  other  documents  are  maintained  and  that  the  correct  data 
editor  is  used  to  manipulate  embedded  document  components. 

3.8.1 1  J.l  Standard.  Table  3.8-76  presents  standards  for  compound  document  editing. 


TABLE  3.8-76  Compound  document  editing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

. .  ■  '  .flwtn  ■  .  f . ■ 

lEgall 

3.8.11.3.2  Alternative  specification.  Microsoft's  proprietary  specification,  OLE,  provides 
compound  document  editing  abilities. 

3JL11.3.3  Standard  deficiencies.  None  known. 

3.8.11.3.4  Portability  caveats.  OpenDoc  is  presently  available  only  on  proprietary  operating 
systems,  but  development  of  a  reference  port  to  Unix  is  ongoing. 

3.8.11.3 5  Related  standards.  The  following  standards  are  related  to  compound  document 
editing: 


a.  OMG  Common  Object  Request  Broker  Architecture  (CORBA)  ver.  2. 
3.8.11.3.6  Recommendations.  There  are  no  approved  standards  to  recommend  at  this  time. 
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3.8.  11.4  Compound  document  storage.  Document  embedding  implies  a  certain  structure  to  the 
"container"  document  Ensuring  that  applications  which  operate  on  compound  documents  can 
quickly  and  properly  access  the  appropriate  subdocuments  requires  agreement  on  this  internal 
structure. 

3.8.11.4.1  Standard.  Table  3.8-77  presents  standards  for  compound  document  storage. 


TABLE  3.8-77  Compound  document  storage  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

IETF 

HyperText  Meifcup  Leaf uafe  (HTML)  v.2.0 

RFC  1166:1995 

lofomubooil 

(Approved) 

CPC 

IETF 

Mukipuipoee  Interact  Mail  Etumiom  (MIME): 
MadMaitau  for  Specifying  aod  Deacribiof  the  Foraiat  of 
btemet  MeauceBodiea 

RFC  1521:1993 

Infonaabonel 

(Approved) 

1 

■SB 

■Sill 

3.8.11.4.2  Alternative  specification.  Microsoft's  proprietary  specification,  OLE,  defines  a 
compound  document  storage  format. 

3.8.11.4.3  Standard  deficiencies.  HTML  provides  for  document  linking  only,  while  MIME 
specifies  just  an  embedded  document  storage  format.  Unfortunately  there  is  no  standard  way  to 
combine  the  two  specifications  which  provides  the  use  with  both  abilities. 

3.8. 11.4.4  Portability  caveats.  OpenDoc  is  presently  available  only  on  proprietary  operating 
systems,  but  development  of  a  reference  port  to  Unix  is  ongoing. 

3.8.11.4.5  Related  standards.  The  following  specification  is  related  to  compound  document 
storage: 


a.  ISO  8879: 1 986  -  Standard  Generalized  Markup  Language  (SGML). 

3.8.1 1.4.6  Recommendations  Although  MIME  is  listed  as  a  "draft  internet  standard",  it  is  in 
widespread  use  and  has  been  generally  accepted  by  the  Internet  community.  MIME  is 
recommended  for  multi-part  structured  document  storage  and  exchange  on  those  systems  which 
require  interoperability  with  the  larger  Internet  community. 
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3.8. 11.5  Compound  document  interoperability.  The  ability  to  access  compound  documents 
created  in  conformance  to  one  specification,  or  on  a  particular  operating  system,  by  the  document 
editors  of  a  different  specification,  or  by  the  same  standard,  but  on  a  different  operating  system,  is 
critical  to  the  success  of  compound  document  technology  in  the  workplace. 

3.8.1 1.5.1  Standard.  Table  3.8-78  presents  standards  for  compound  document  interoperability. 


TABLE  38-78  Compound  document  interoperability  standards 


Standard  Sponsor  Standard 

TyP* 

Standard 

Reference 

ia 

Hflil 

i 
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3.8.11.5.2  Alternative  specification.  Microsoft's  OLE  specification  makes  no  provision  for 
interoperability  with  other  compound  document  formats.  Fujitsu's  Fresco  project  provides 
facilities  which  allow  it  to  interoperate  with  OLE  documents. 

38.115J  Standard  deficiencies.  None  known. 

3.8.11.5.4  Portability  caveats.  OpenDoc  is  presently  available  only  on  proprietary  operating 
systems,  but  development  of  a  reference  port  to  Unix  is  ongoing. 

7.8.11.5 £  Related  standards.  The  following  standard  is  related  to  compound  document 
interoperability: 

a.  OMG  Common  Object  Request  Broker  Architecture  (CORBA)  ver.  2. 
3.8.11.5.6  Recommendations.  There  are  no  approved  standards  to  recommend  at  this  time. 
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3 A 12  Portable  device  driver  environment  Operating  systems  access  I/O  devices  through  the 
use  of  device-specific  software  modules  called  device  drivers.  Device  driver  interface  standards 
limit  the  interaction  between  a  device  driver  and  the  rest  of  the  system  (i.e.  the  operating  system, 
the  applications,  the  processor  architecture,  and  the  interconnecting  busses  and/or  channels)  to 
well-defined  interfaces.  This  enables  highly  portable  device  drivers  to  be  developed  independent 
of  the  target  platform,  operating  system,  or  interconnect  scheme.  For  commercial  systems,  where 
device  drivers  are  written  by  Independent  Hardware  Vendors  (IHVs),  this  permits  a  single  driver, 
delivered  with  a  hardware  board  or  device,  to  be  utilized  in  whatever  system  the  device  is  installed 
by  the  end  user.  In  military  systems,  many  devices  are  not  off-the-shelf,  but  are  highly  specialized 
and  developed  specifically  for  the  military  market;  more  often  than  not,  the  burden  of  device 
driver  development  falls  on  the  application  developer,  because  the  device  vendor  has  neither  the 
resources  nor  the  market  to  supply  device  drivers  for  all  possible  targets;  the  ability  to  develop 
and  maintain  a  single  portable  driver,  whether  written  by  the  device  vendor  or  the  application 
developer,  clearly  reduces  the  cost  of  supporting  the  device. 

Device  driver  code  is  typically  quite  complex;  tl:  •  -.in  ity  of  device  driver  design  and  coding  often 
strongly  affects  the  overall  performance  of  a  sy  Me , . ,  > !  If  the  consequences  of  bugs  in 

device  drivers  are  far  more  severe  than  those  of  uuc  .»  ap^iicr.,',*'"  programs;  device  drivers  run 
with  much  greater  privilege,  directly  manipulate  hardwarr  „c-(>  uc ■  s,  and  often  must  comply  with 
severe  time  constraints.  Historically,  drivers  have  needed  to  l  o  'ed  for  each  hardware 
platform  and  operating  system  version;  also,  driver  updates  ai-  • ;  ,'intly  required  to  provide 
new  capabilities  or  to  utilize  hardware  upgrades.  Given  theii  "i  acixity,  this  becomes  a 
considerable  maintenance  burden  requiring  significant  development  resources.  As  the  number  of 
devices,  operating  systems,  and  platforms  grows  dramatically,  as  is  the  trend  today,  the  number  of 
different  device  drivers  becomes  unmanageable.  Portable  device  driver  interface  standards  are  a 
way  to  reduce  this  burden,  resulting  in  a  one  device  -  one  driver  approach  which  allows  developer 
resources  to  be  devoted  to  quality  of  implementation,  not  quantity  of  drivers. 

Portable  interfaces  for  device  drivers  must  allow  any  application  request  for  an  I/O  action  (open, 
close,  read,  write,  control,  status,  synchronous,  asynchronous,  synchronized,  etc.)  to  be  honored 
by  the  appropriate  driver;  for  a  driver  to  deal  with  multiple  applications  contending  for  the  same 
device;  for  both  programmed  and  Direct  Memory  Access  data  transfers  between  the  device  and 
the  application's  data  area;  for  servicing  hardware  interrupts;  and  for  a  driver  to  implement  a  layer 
of  protocol  between  a  higher  level  driver  (or  the  application)  and  a  lower  level  driver  (or 
hardware  entity).  Yet,  the  interfaces  must  remain  operating  system  neutral  in  spite  of  variations  in 
the  underlying  OS  memory  management,  synchronization  models,  kernel  premptibility,  multi¬ 
threading,  and  dynamic  loading  capabilities.  Likewise,  the  interfaces  must  remain  platform  neutral 
in  the  \  resence  of  proprietary  I/O  busses,  cached  and  buffered  I/O  data  paths,  alignment 
constraints,  mixed  byte  ordering,  and  variations  in  processor  I/O  and  interrupt  architecture. 

Currently,  the  only  known  effort  which  meets  these  criteria  is  Project  UDI  (Uniform  Driver 
Interface),  initiated  by  a  multi-vendor  working  group  comprised  of  several  systems  vendors  and 
IHVs.  This  group  first  documented  a  set  of  40  functional  requirements  for  an  environment  to 
support  portable  device  drivers,  then  prepared  a  specification  of  the  interfaces  between  such  an 
environment  and  the  device  drivers  themselves.  In  addition,  the  group  conceived  a  Metalanguage 
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concept  to  account  for  special  interfaces  from  application  to  driver  or  between  drivers  for  each 
specific  class  of  device  (e.g.  all  pointer  devices  might  require  a  special  calibrate  interface,  while  all 
removable  media  devices  might  require  an  unload/eject  interface);  a  number  of  standard 
Metalanguages,  and  their  associated  interface  specifications,  were  developed  by  the  UD1  group. 
Having  specified  a  draft  UDI  environment  and  set  of  standard  Metalanguages,  the  group  has 
embarked  on  an  aggressive  prototyping  effort  designed  to  demonstrate  proof-of-concept  and  to 
further  refine  the  specifications.  It  is  anticipated  that  this  prototyping  effort  will  lead  to  wide¬ 
spread  industry  adoption  of  UDI  technology  and  inclusion  of  UDI  compliant  environments  and 
drivers  in  future  product  releases.  The  de-facto  industry  standard  based  on  the  UDI  specifications 
will  then  be  ready  to  be  turned  into  a  national  and/or  international  standard  through  an  IEEE  (or 
similar)  standards  process. 

The  UDI  specifications  have  been  developed  largely  based  on  the  UDI  group's  knowledge  of  the 
commonly  supported  and  marketed  device  classes  in  the  commercial  sector,  and  therefore  may 
not  provide  all  necessary  interfaces  to  support  either  specialized  military  devices  and 
interconnects,  or  newer  industry  standards  and  draft  standards  for  devices  and  interconnects. 

The  UDI  specifications  are  sufficiently  complete  to  support  core  driver  functionality  for  standard 
commercial  device  classes;  however,  there  are  several  known  deficiencies  which  will  be  resolved 
as  the  UDI  Group  completes  their  prototyping  efforts  and  completes  Rev.  1.0.  However,  any  such 
standard  can  address  only  those  platform,  interconnect,  and  device  capabilities  known  to  the 
members  of  the  developing  group;  therefore  it  is  recommended  that  organizations  expecting  to 
use  this  standard  participate  in  its  formative  stages,  and  ensure  that  any  unique  requirements  are 
identified  and  technical  solutions  proposed.  This  process  has  already  begun  for  Fibre  Channel  and 
Scalable  Coherent  Interface,  and  should  be  extended  to  address  any  other  new  I/O  technologies 
which  might  not  be  supported  by  the  current  draft  specification.  This  recommendation  particularly 
extends  to  standard  UDI  Metalanguages  (device  class  specific  interfaces)  for  unique  devices 
vhich  are  conceptually  quite  different  from  common  commercially  available  devices. 

The  UDI  Group's  major  participants  are 

Adaptec,  Inc.; 

Digital  Equipment  Corporation; 

Hewlett-Packard  Company; 

Interphase  Corporation; 

Novell,  Inc.; 

The  Santa  Cruz  Operation,  Inc.;  and 

Sun  Microsystems,  Inc. 

Two  other  standardization  efforts  are  often  considered  device  driver  interface  standards: 
Microsoft's  Plug  and  Play  and  another  industry  group’s  Intelligent  Input/Output  (120) 
specification.  Plug  and  Play,  while  it  does  specify  device  driver  interfaces,  is  a  hybrid 
(cooperating  hardware  and  software)  solution  to  an  entirely  different  problem,  that  of  making 
devices  self-identifying  and  automatically  configurable;  it  does  not  supportportability  of  device 
drivers  across  operating  systems  or  platforms.  120,  on  the  other  hand,  does  address  the  driver 
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portability  problem,  but  provides  a  hybrid  hardware/software  solution  which  allows  a  portion  of 
each  device  driver  (the  part  which  specifically  manipulates  the  device  hardware)  to  be  written 
portably,  provided  that  this  part  is  executed  by  a  standard  I/O  processor  chip  which  communicates 
(via  message  passing)  with  the  operating  specific  portion  of  the  driver;  introduction  of  this 
additional  processor  requires  that  the  120  specification  standardize  not  only  the  device  driver 
interfaces,  but  also  the  IOP  hardware  architecture,  transport  protocols  between  host  and  IOPs, 
transport  driver  interfaces,  message  protocol  over  the  transport,  and  initialization  and 
configuration  of  the  IOP  itself.  The  UD1  group  feels  that  both  efforts  will  benefit  from  exploiting 
the  inherent  synergy  between  the  two  groups,  and  should  work  jointly  toward  a  truly  universal 
device  driver  standard.  To  this  end,  they  have  begun  to  map  out  several  models  which  would 
support  both  standards  working  together. 

The  120  specification  is  not  available  to  non-members  of  the  120  Special  Interest  Group  without 
signing  of  a  non-disclosure  agreement  and  payment  of  a  fee.  Because  of  this,  the  120  specification 
cannot  reasonably  be  considered  a  standard  suitable  for  open  systems.  Perhaps  when  the  120  and 
UDI  groups  begin  to  work  toward  a  common  specification,  this  restriction  will  be  lifted. 

The  following  BS  As  outline  the  interfaces  and  functionality  that  various  kinds  of  device  drivers 
will  require  from  a  portable  device  driver  environment 

3.8.12.1  Multi-threading.  Since  driver-to-environment  interfaces  are  typically  invoked  from  the 
operating  system  kernel,  it  is  important  that  such  interfaces  relinquish  the  processor  whenever  the 
associated  operation  cannot  be  completed  immediately,  then  regain  control  and  continue  when 
that  operation  is  later  completed.  A  driver  may  have  several  logical  threads  of  execution  pending 
simultaneously.  Each  such  thread  may  be  awaiting  a  different  resource  or  event  and  in  some  s'age 
of  completion,  and  each  such  thread  generally  needs  a  separate  data  area  associated  with  the 
operation  being  performed.  Unfortunately,  a  dynamic  memory  allocation  operation  itself  may  need 
to  await  sufficient  memory  resources.  Multi-threading  services  provide,  upon  entry  to  a  driver 
function,  adequate  storage  for  a  single  service  request  to  be  queued,  and  additional  services  for  a 
driver  to  regain  control  once  an  operation  has  been  initiated  (but  not  necessarily  completed),  to  be 
notified  when  an  operation  has  been  completed,  and  to  obtain  more  storage  to  be  used  for 
subsequent  concurrent  service  requests.  Also,  services  to  free  storage  allocated  for  a  thread  of 
execution,  and  to  support  cancellation  of  pending  service  requests  are  provided. 

3.8.12.1.1  Standards.  Table  3.8-79  presents  standards  for  multi-threading. 


TABLE  3.8-79  Multi-threading  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecvclc) 

CPC 
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3.8.12.1.2  Alternative  specification.  Predecessors  to  UDI  technology  have  been  developed  by 
several  of  the  UDI  Group's  member  companies,  and  serve  to  partially  solve  the  device  driver 
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portability  problem  within  the  domain  of  each  vendor's  operating  system  and  hardware 
architecture  support  Most  notably,  Sun  Microsystems’  Solaris  Driver  Device  Interface/Driver 
Kernel  Interface  (DDI/DKI),  Novell's  UnixWare  Portable  Device  Interface  (PDI),  and  DEC'S 
OSF/1  processor  abstraction  interfaces  served  as  starting  points  for  the  development  of  UDI 
technology.  The  API  specifications  for  these  solutions  are  published  as  part  of  each  vendor's 
operating  system  documentation  set  Although  these  specifications  surely  support  multi-threaded 
driver  code,  and  most  of  the  other  BSAs,  none  constitutes  a  comprehensive  open-systems 
portability  solution  across  the  various  operating  systems;  this  is  the  goal  of  UDI. 

3i.12.lJ  Standard  deficiencies.  Rules  for  freeing  a  previously  freed  token  are  not  yet  specified. 

3.8.12.1.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.1.5  Related  standards.  None  for  this  service  area. 

3.8.12.1.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.2  Buffer  management.  Drivers  typically  require  intermediate  user  data  buffers  to  cany 
the  line  data  between  an  application  and  die  underlying  device.  Such  buffers  are  considered 
logically  contiguous,  but  may  be  virtually  and  physically  segmented.  Buffer  management  services 
provide  for  allocation  and  deallocation  of  such  buffers  from  a  pool  common  to  all  drivers,  for 
writing  to,  reading  from,  and  copying  these  buffers,  for  determining  buffer  constraints,  and  for 
segmentation  and  reassembly  of  buffers  in  support  of  networking  protocols. 

3.8.12.2.1  Standards.  Table  3.8-80  presents  standards  for  buffer  management 


TABLE  3.8-80  Buffer  management  standards 


Standard  Sponsor 
Type 

Standard 

Standard 

Reference 

Status 

DoD 

^Lifecycle) 
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3.8.12.2.2  Alternative  specification.  Sun  Microsystems'  DDI/DK1,  Novell's  UnixWare  PDI,  and 
DEC's  OSF/1  processor  abstraction  interfaces. 

3.8.12.2.3  Standard  deficiencies.  Buffer  constraints  interfaces  are  incomplete  in  UD1  version 
0.75.  Buffer  segmentation/reassembly  interfaces  are  proposed  in  UDI  version  0.75.  Insufficient 
UDI  usage  base  to  rule  out  other  deficiencies. 

3.8.12.2.4  Portability  caveats.  Insufficient  usage  base  to  assess. 

3.8.12.2.5  Related  standards.  None  for  this  service  area. 

3.8.12.2.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.3  Device  driver  memory  management .  In  addition  to  buffers,  drivers  often  require 
dynamic  allocation  of  virtually  contiguous  memory.  Since  drivers  do  not  necessarily  run  in  the 
context  of  an  operating  system  process,  the  language  specific  management  primitives  (e.g. 
malloc/free  or  new/delete)  cannot  be  used.  Memory  management  services  allow  a  driver  to 
allocate  and  free  memory,  and  to  discover  the  memory  allocation  limits  of  the  system. 

3.8.12.3.1  Standards.  Table  3.8-81  presents  standards  for  device  driver  memory  management 


TABLE  3.8-81  Device  driver  memory  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

BIEEiil 

3.8.12.3.2  Alternative  specification.  Sun  Microsystems'  DDI/DKI,  Novell's  UnixWare  PDI,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8.12.3.3  Standard  deficiencies.  A  separate  interface  to  allocate  movable  structures  has  not  yet 
been  defined.  The  maximum  guaranteed  size  for  an  allocation  request  needs  to  be  tevisited.  A 
memory  allocation  interface  which  accepts  minimum,  maximum,  and  granularity  values  still  needs 
to  be  provided. 

3.8.12.3.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.3.5  Related  standards.  The  following  standards  are  related  to  device  driver  memory 
management  standards: 

a.  IEEE  P1003.1j:  Realtime  Extension  to  POSIX  (memory  Management) 

b.  ISO  8652:1995:  Programming  Languages  -  Ada  (allocators) 

c.  ISO/IEC  9899:  Programming  Languages  -  C  (malloc/calloc/realloc/free) 

d.  ANSI  X3J16  WG21/N0678:  Programming  Languages  -  C++  (new/delete) 

3.8.12.3.6  Recommendations.  UDI  is  recommended  becat  :  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3 A  12.4  Programmed  I/O.  A  driver  which  actually  controls  a  device  must  read  and  write 
various  control  and  status  registers,  FIFOs,  and  dual-ported  memory  implemented  by  that  device 
in  hardware.  In  the  Programmed  I/O  (PIO)  model,  the  processor  directs  data  between  the  device 
and  memory  or  buffers;  the  device  is  simply  commanded  by  the  processor  to  accept  or  provide  the 
requested  data.  There  may  be  constraints  on  the  atomicity  of  device  data  accesses,  so  8-bit,  16- 
bit,  and  32-bit  (and  possibly  64-bit)  transfers  must  be  supported.  Programmed  I/O  services  allow 
the  driver  to  obtain  a  handle  for  a  specific  device,  to  determine  the  atomicity  supported  by  the 
device  (and  intervening  bus  bridges),  and  to  transfer  data  to  and  from  the  device,  either  an  atom  at 
a  time  or  in  blocks. 

3.8.12.4.1  Standards.  Table  3.8-82  presents  standards  for  programmed  I/O. 


TABLE  3.8-82  Programmed  I/O  standards 


Standard 
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Standard 

Standard 
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3.8.12.4.2  Alternative  specification.  Sun  Microsystems'  DDI/DKI,  Novell's  UnixWare  PDi,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8.12.4  J  Standard  deficiencies.  PIO  accesses  may  fail  and  need  to  return  status,  but  currently 
do  not  support  asynchronous  return  of  such  status;  this  needs  to  be  resolved.  Peer  to  peer  PIO 
issues  need  to  be  resolved.  PIO  interfaces  to  access  hardware  that  may  not  be  responding  on  the 
bus  (for  initial  and  diagnostic  probing)  are  still  not  defined. 

The  UDI  specifications  have  been  developed  largely  based  on  the  UDI  group's  knowledge  of  the 
commonly  supported  and  marketed  device  classes  in  the  commercial  sector,  and  therefore  may 
not  provide  all  necessary  interfaces  to  support  either  specialized  military  devices  and 
interconnects,  or  newer  industry  standards  and  draft  standards  for  devices  and  interconnects. 

3.8.12.4.4  Portability  caveats.  Insufficient  UDI  usage  base  to  fully  assess. 

UDI  achieves  portability  by  specifying  an  environment  which  shields  device  drivers  from  the 
specifics  of  the  target  operating  system,  processor,  and  hardware  I/O  interface.  Such  an 
environment  must  be  implemented  and  re-implemented  for  each  combination  of  target  platform, 
operating  system,  and  interconnect  scheme  (bus  architecture)  intended  to  support  UDI 
conforming  portable  device  drivers.  Because  system  and  device  vendors  have  a  considerable 
investment  in  native  device  drivers  for  existing  systems,  implementations  of  such  an  environment 
must  co-exist  and  cooperate  with  these  existing  drivers,  and  permit  a  phased  transition  to 
completely  UDl-based  drivers;  the  old  driver  environments  may  need  to  be  supported  indefinitely. 
To  simplify  this  co-existence,  system  vendors  may  choose  to  implement  the  UDI  environment  as  a 
shell  on  top  of  the  older,  system  specific  environment;  users  should  be  aware  of  the  performance 
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degradation  to  be  expected  with  such  a  layered  implementation,  and  encourage  system  vendors  to 
integrate  die  UDI  environment  more  fully  into  their  operating  systems  as  soon  as  possible. 

Even  in  a  system  where  UDI  has  been  bound  as  efficiendy  as  possible  to  the  hardware  and 
operating  system,  users  must  be  aware  that  portability  almost  always  imposes  some  performance 
penalty;  the  UDI  interfaces  are  portable  replacements  for  down-and-dirty  use  of  specific 
hardware  capabilities  such  as  memory  mapped  device  registers,  interrupt  masking,  mutual- 
exclusion  primitives  (test-and-set  instructions),  I/O  channel  commands,  and  DMA  controllers. 

Just  as  we  have  grown  to  accept  a  modest  performance  penalty  to  use  a  High  Order  Language  to 
gain  portability  over  hand  optimized  assembly  code,  so  we  must  understand  and  accept  the  price 
of  device  driver  portability.  Although  UDI  interfaces  have  been  designed  to  allow  implementation 
performance  to  be  optimized  to  the  greatest  extent  possible,  it  is  still  likely  that  UDI  conforming 
drivers  will  underperform  system-specific  drivers.  This  is  not  a  bad  thing,  just  another  engineering 
tradeoff  which  must  be  considered  by  system  engineers. 

3.8.12.4.5  Related  standards.  The  following  standard  is  related  to  device  driver  programmed  I/O 
standards: 


a.  IEEE  1212:1991:  IEEE  Standard  for  CSR  Architecture 

3.8. 12.4.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.5  Direct  Memory  Access.  Some  devices  are  capable  of  Direct  Memory  Access  (DMA). 
Such  devices  are  capable  of  independently  directing  the  transfer  of  data  between  the  device  and 
memory  without  processor  intervention.  However,  prior  to  such  transfers,  the  processor  must  set 
up  pathways  and  configure  resources  to  make  the  DMA  possible,  and  then  pass  information  (an 
address  and  a  length,  or  a  scatter-gather  structure)  to  the  device  so  that  the  device  knows  the 
intended  memory  origin  or  destination  of  the  data.  The  manner  in  which  this  is  done,  and  the 
device's  constraints  on  size,  alignment,  scatter-gather  structure  format,  and  other  attributes  of 
DMA  transfers  vary  from  device  to  device.  Direct  Memory  Access  services  allow  the  driver  to 
discover  the  DMA  constraints,  to  bind/unbind  buffers  to  DMA  resources,  and  to  deal  efficiently 
with  inbound  data  whose  length  and  structure  may  not  be  known  apriori.  The  actual  notification 
to  the  device  to  begin  a  DMA  transfer  is  a  Programmed  I/O  operation,  although  the  device  may 
access  control  information  (scatter-gather  lists,  etc.)  via  a  DMA  mechanism. 

3.8.12.5.1  Standards.  Table  3.8-83  presents  standards  for  direct  memory  access. 


TABLE  3.8-83  Direct  Memory  Access  standards 
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3.8.12.5.2  Alternative  specification.  Sun  Microsystems'  DD1/DK1,  Novell's  UnixWare  PDI,  and 
DEC's  OSF/1  processor  abstraction  interfaces. 

3.8.12.5.3  Standard  deficiencies.  Peer  to  peer  DMA  issues  need  to  be  resolved. 

The  UDI  specifications  have  been  developed  largely  based  on  the  UD1  group's  knowledge  of  the 
commonly  supported  and  marketed  device  classes  in  the  commercial  sector,  and  therefore  may 
not  provide  all  necessary  interfaces  to  support  either  specialized  military  devices  and 
interconnects,  or  newer  industry  standards  and  draft  standards  for  devices  and  interconnects. 

3.8.12.5.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess.  See  Programmed  I/O  BSA 
for  portability  vs.  performance  concerns. 

3.8.12.5.5  Related  standards.  The  following  standards  are  related  to  device  driver  Direct 
Memory  Access  standards: 

a.  IEEE  1212.1:1993:  IEEE  Std.  for  CSR  Architecture  (DMA  Framework) 

b.  IEEE  PI 285:  IEEE  Draft  Standard  for  Scalable  Storage  Interface  (S2I) 

3.8.12.5.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.6  Device  driver  time  management  Drivers  often  need  to  perform  an  operation 
periodically  (e.g.  polling  a  device  not  capable  of  signaling  I/O  completion  via  an  interrupt)  or  after 
a  delay  (e.g.  to  deal  with  timing  characteristics  of  a  device,  or  for  establishing  a  timeout  for  device 
response).  A  driver  thread  therefore  may  require  waiting  for  a  time-related  event  rather  than  (or  in 
addition  to)  a  resource  or  device  related  event  (i.e.  interrupt).  Since  drivers  do  not  necessarily  run 
in  the  context  of  an  operating  system  process,  portable  application  level  timer  primitives  cannot  be 
used.  Time  management  services  provide  for  an  abstract  notion  of  time  (including  conversion 
to/from  microseconds  and  discovering  supported  resolution),  starting  a  one-shot  or  periodic 
timer,  notification  of  timer  expiration,  and  canceling  a  pending  timer. 

3.8.12.6.1  Standards.  Table  3.8-84  presents  standards  for  device  driver  time  management 


TABLE  3,8-84  Device  driver  time  management  standards 
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3.8.12.6.2  Alternative  specification.  Sun  Microsystems'  DDI/DK1,  Novell's  UnixWare  PDI,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8.12.6 3  Standard  deficiencies.  None  currently  identified  for  this  service  area. 

3.8.12.6.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.6.5  Related  standards.  None  for  this  service  area. 

3.8.12.6.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.7  Device  node  management  Before  an  application  can  use  (i.e.  open)  a  device,  it  must 
be  able  to  locate  that  device  by  some  logical  name,  determine  if  the  device  exists,  and  determine 
the  device's  status  and  attributes;  it  is  the  driver's  responsibility  to  register  this  information  in  a 
device  tree  (a  database),  and  the  environment's  responsibility  to  associate  open  devices  with  the 
correct  driver.  Device  node  management  services  allow  each  driver  to  participate  in  the  building 
of  a  device  tree,  and  both  drivers  and  applications  to  search  the  tree  and  query  attributes  and 
status  of  devices. 

3.8.12.7.1  Standards.  Table  3.8-85  presents  standards  for  device  node  management 


TABLE  3.8-85  Device  node  management  standards 
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3.8.12.7.2  Alternative  specification.  Sun  Microsystems'  DDI/DK1,  Novell's  UnixWare  PD1,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8.12.7.3  Standard  deficiencies.  Standard  attributes  have  not  yet  been  defined.  Interface  for 
searching  for  a  device  tree  node  is  still  under  investigation.  Bus/interconnect  probe  i  iterfaces  (to 
help  build  the  device  tree)  have  not  yet  been  defined. 

3.8.12.7.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.7.5  Related  standards.  None  for  this  service  area. 

3.8.12.7.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  soludon  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.8  Mutual  exclusion.  In  drivers  which  support  concurrent  execution  "f  multiple  threads  of 
execution,  it  is  essential  that  access  to  resources  shared  among  such  thre.  d ,,  such  as  buffers  and 
flags,  be  synchronized  to  prevent  race  conditions.  Most  drivers  must  support  at  least  two 
concurrent  threads,  for  example  a  read  operation  and  an  interrupt  handler.  Since  drivers  do  not 
necessarily  run  in  the  context  of  an  operating  system  process,  portable  application  level  mutual 
exclusion  primitives  cannot  be  used.  Mutual  exclusion  services  ensure  that  two  threads  of  driver 
execution  can  each  guarantee  that  certain  sections  of  code  in  one  thread  cannot  be  pre-empted  by 
certain  sections  in  the  other. 

3.8.12.8.1  Standards.  Table  3.8-86  presents  standards  for  mutual  exclusion. 


TABLE  3.8-86  Mutual  exclusion  standards 
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3.8.12.8 2  Alternative  specification.  Sun  Microsystems'  DDI/DKI,  Novell's  UnixWare  PDI,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8. 12.8 3  Standard  deficiencies.  None  currently  identified  for  this  service  area. 

3.8.12.8.4  Portability  caveats.  Insufficient  UD1  usage  base  to  assess.  See  Programmed  I/O  BSA 
for  portability  vs.  performance  concerns. 

3.8.12.8.5  Related  standards.  The  following  standards  are  related  to  devil  ;  driver  mutual 
exclusion  standards: 

a.  IEEE  1003.1b:  1993:  Realtime  extension  to  PCS1X  (semaphores) 

b.  IEEE  1003.1c:1995:  Threads  Extension  to  POSIX  (mutexes) 

3.8.12.8.6  Recommendations.  I IDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.9  Tracing  and  logging.  An  operating  system  with  which  device  drivers  co-exist  typically 
provides  tracing  and  logging  facilities  as  part  of  an  overall  fault  isolation  strategy;  drivers  are 
expected  to  support  this  strategy.  Logging  simply  requires  that  a  driver  record  unusual 
occurrences  which  may  affect  functionality  of  the  driver,  device,  or  subsystems  using  the  driver. 
Tracing  requires  on-demand  recording  of  sufficient  information  to  reconstruct  a  logical  sequence 
of  events  within  the  driver,  and  is  controlled  by  an  external  operating  system  unique  trace  facility. 
Tracing  and  logging  services  allow  drivers  to  participate,  in  a  portable  fashion,  in  the  operating 
system's  unique  tracing  and  logging  activities.  Interfaces  to  write  trace  and  log  data,  and  to 
respond  to  trace  facility  requests  are  provided. 

3.8.12.9.1  Standards.  Table  3.8-87  presents  standards  for  tracing  and  logging. 


TABLE  3.8-87  Tracing  and  logging  standards 
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3.8.12.9.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.12.9.3  Standard  deficiencies.  These  interfaces  are  defined,  but  still  under  investigation. 
3X12.9.4  Portability  caveats.  Insufficient  UDI  usage  to  assess. 

3.8.12.9.5  Related  standards.  The  following  standard  is  related  to  device  driver  tracing  and 
logging  standards: 

a.  IEEE  1003.1 ‘'•SRASS  Amendment  to  POSIX 

3.8.12.9.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services,  promises 
to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being  developed 
by,  and  backed  by,  a  substantial  portion  of  f’  computer  industry. 
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3.8.12.10  Inter-module  communication.  Often,  the  apparent  functionality  of  a  device  is 
implemented  by  several  cooperating  drivers;  since  such  drivers  may  not  be  able  to  share  memory 
or  synchronize  access  to  shared  resources,  a  loosely  coupled  form  of  inter-  module 
communication  is  necessary.  Since  drivers  do  not  necessarily  run  in  the  context  of  an  operating 
system  process,  portable  application  level  IPC  primitives  cannot  be  used.  Inter-module 
communication  services  allow  a  driver  to  establish  a  connection  to  another  driver  through  which 
that  driver's  services  may  be  invoked  just  as  if  invoked  directly  by  the  environment  on  behalf  of  an 
application.  For  higher  performance,  cooperating  drivers  may  also  utilize  shared  memory  when 
supported;  therefore,  inter-module  communication  services  should  also  allow  a  driver  to  share 
memory  with  other  drivers,  and  synchronize  access  to  that  shared  memory. 

3.8.12.10.1  Standards.  Table  3.8-88  presents  standards  for  inter-module  communication. 


TABLE  3.8-88  Inter-module  communication  standards 
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3.8.12.10.2  Alternative  specification.  Sun  Microsystems'  DDI/DK1,  Novell's  UnixWare  PDI,  and 
DEC'S  OSF/1  processor  abstraction  interfaces. 

3.8.12.10.3  Standard  deficiencies.  Shared  memory  interfaces  are  not  currently  specified. 

3.8.12.10.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess.  See  Programmed  I/O 
BSA  for  portability  vs.  performance  concerns. 

3.8.12.10.5  Related  standards.  The  following  standard  is  related  to  device  driver  inter-module 
communication  standards: 

a.  ISO/IEC  9945-1:1996:  POS1X  System  API 

3.8.12.10.6  Recommendations.  UDI  is  recommended  because  it  piovides  these  services, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3Ai2.il  Locking  protocol.  Drivers  normally  receive  requests  and  provide  responses  to  either  a 
higher  level  driver,  or  the  application  (via  the  portable  driver  environment).  The  motivation  for 
driver  locking  is  to  temporarily  give  control  of  an  I/O  driver  to  an  outside  subsystem  (e.g. 
diagnostics,  configuration)  other  than  the  driver's  normal  higher  driver,  for  the  purpose  of 
allowing  the  outside  subsystem  to  perform  an  undisturbed  sequence  of  operations  (requests)  on 
the  driver.  While  a  driver  is  locked,  its  normal  flow  of  requests  from  its  higher  driver  is 
suspended.  Normal  requests  are  queued  up,  and  will  be  processed  after  the  driver  is  unlocked. 
Locking  protocol  services  allow  the  outside  subsystem  to  lock  and  unlock  the  driver,  and  if  the 
lock  will  be  disruptive  (i.e.  the  outside  subsystem's  request  cannot  be  transparently  interleaved 
with  normal  traffic),  to  reset  the  driver  to  a  known  state  and  have  it  recover  or  propagate  a 
failure/retry  status  to  its  normal  user. 

3.8.12.11.1  Standards.  Table  3.8-89  presents  standards  for  locking  protocol. 


TABLE  3.8-89  Locking  protocol  standards 
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3.8.12.11.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8. 12.11-3  Standard  deficiencies.  These  interfaces  are  sketched  out  in  concept,  but  still  under 
investigation  and  not  yet  defined. 

3.8.12.11.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.11.5  Related  standards.  None  for  this  service  area. 

3.8.12.11.6  Recommendations.  UDI  is  recommended  because  it  plans  to  provide  these  services, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  a  id  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.12  Powerfail  recovery.  If  power  is  lost  to  a  peripheral  and/or  the  main  processor,  but 
memory  has  been  preserved,  it  is  desirable  that  either  VO  operations  that  were  in  progress  when 
power  failure  occurred  be  restarted  or  completed;  failing  that,  applications  or  higher  level  drivers 
(which  may  themselves  have  been  recovered  by  the  overall  powerfail  recovery  strategy  of  the 
operating  system)  should  be  notified  of  VO  failure.  Powerfail  recovery  services  allow  a  driver  to 
request  notification  of  powerfail  and  poweron  warning  events  so  that  it  may  recover  if  possible,  or 
notify  higher  levels  of  a  failure  if  not 

3.8.12.12.1  Standards.  Table  3.8-90  presents  standards  for  powerfail  recovery. 


TABLE  3.8-90  Powerfail  recovery  standards 


Standard 
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Sponsor 

Standard 

Standard 

Reference 

Status 
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3.8.12.12.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 
3.8.12.12 3  Standard  deficiencies.  These  interfaces  are  defined,  but  still  under  investigation. 

3.8.12.12.4  Portability  caveats.  Insufficient  UDI  usage  to  assess. 

3.8.12.12.5  Related  standards.  None  for  this  service  area. 

3.8.12.12.6  Recommendations.  UDI  is  recommended  because  it  provides  these  services, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.13  Management  metalanguage.  A  portable  driver  environment,  in  the  process  of 
building  up  or  tearing  down  a  pathway  from  an  application  (or  outside  subsystem)  through  one  or 
more  drivers  to  a  device,  must  pass  management  requests  to  the  drivers  involved.  A  management 
metalanguage  defines  service  interfaces  to  drivers  for  initialization,  binding  to  other  drivers, 
unbinding,  and  diagnostics. 

3.8.12.13.1  Standards.  Table  3.8-91  presents  standards  for  management  metalanguage. 


TABLE  3.8-91  Management  metalanguage  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 
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3.8.12.13.2  Alternative  specification.  The  UNIX  System  V  (SVID)  specification  defines  a 
STREAMS  capability  for  establishing  a  data/control  pathway  through  several  drivers  to  a  device. 

3.8. 12.133  Standard  deficiencies.  System  management  and  diagnostic  portions  of  this 
metalanguage  are  incomplete/proposed. 

3.8.12.13.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.13.5  Related  standards.  None  for  this  service  area. 

3.8.12.13.6  Recommendations.  UDI  is  recommended  because  it  defines  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3JL12.14  Bus  bridge  metalanguage.  A  driver  often  must  access  its  corresponding  hardware 
device  indirectly  via  a  bus  bridge.  Requests  from  the  device  driver  to  the  bus  bridge  driver  and 
from  the  bus  bridge  driver  to  the  device  driver  are  required  to  perform  initial  binding  of  the 
drivers,  as  well  as  to  set  up  and  process  notification  (to  the  device  driver)  of  device  interrupts  via 
the  bus  bridge  driver.  A  bus  bridge  metalanguage  defines  service  interfaces  for  binding  and 
interrupt  registration  operations  invoked  on  a  bridge  driver  by  a  device  driver,  binding  and 
interrupt  registration  operations  invoked  on  a  device  driver  by  a  bridge  driver,  interrupt 
notification  invoked  on  a  device  driver  by  a  bridge  driver,  and  interrupt  acknowledgment  invoked 
on  a  bridge  driver  by  a  device  driver.  Interrupt  handlers  should  be  capable  of  running  in  either  a 
restricted  context  (faster,  low  latency),  or  a  general  context  (slower,  but  no  restrictions  on 
services  available). 

3.8.12.14.1  Standards.  Table  3.8-92  presents  standards  for  bus  bridge  metalanguage. 


TABLE  3.8-92  Bus  bridge  metalanguage  standards 


Standard 
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Standard 
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3.8.12.14.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.12.14.3  Standard  deficiencies.  The  binding  operations  of  this  metalanguage  are  not  yet 
specified. 

3.8.12.14.4  Portability  caveats.  Insufficient  UD1  usage  base  to  assess 

3.8.12.14.5  Related  standards.  None  for  this  service  area. 

3.8.12.14.6  Recommendations.  UDI  is  recommended  because  it  defines  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.15  SCSI  metalanguage.  For  SCSI  devices,  a  device  driver  is  known  as  a  SCSI  peripheral 
driver  (PD),  while  the  bus  bridge  driver  is  known  as  a  SCSI  HBA  driver  (HD).  Requests  from  the 
PD  to  HD  and  from  the  HD  to  PD  are  required  to  perform  initial  binding  of  the  drivers,  to  set  up 
and  process  asynchronous  event  notification,  as  well  as  to  perform  various  SCSI  control  and  I/O 
requests.  A  SCSI  metalanguage  defines  PD  to  HD  interfaces  to  request  a  service  from  the  HBA 
driver,  acknowledge  an  event  from  the  HBA  driver,  or  bind  to  the  HBA  driver;  and  HD  to  PD 
interfaces  to  return  response  information,  notify  the  PD  of  an  asynchronous  event,  or 
acknowledge  a  binding  request 

3.8.12.15.1  Standards.  Table  3.8-93  presents  standards  for  metalanguage. 


TABLE  3.0-93  SCSI  metalanguage  standards 
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3.8.12.15.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3 .8.12.15-3  Standard  deficiencies.  While  this  metalanguage  is  substantially  completely  defined, 
some  unresolved  issues  still  exist 

3.8.12.15.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.15.5  Related  standards.  The  following  standard  is  related  to  device  driver  SCSI 
metalanguage  standards: 

a.  ANSI  X3T9.2  792D:  Draft  Common  Access  Method,  Transport  and  SCSI 
Interface  Module 

3.8.12.15.6  Recommendations.  UDI  is  recommended  because  it  defines  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.16  Network  adapter  metalanguage.  The  portable  driver  environment  needs  to  define  a 
framework  that  provides  interfaces  necessary  to  write  a  networking  driver  that  works  with 
existing  and  future  networking  protocol  stacks  regardless  of  the  OS  and  protocol  stack 
characteristics.  The  framework  must  support  a  universal  set  of  network-related  functions  that 
provide  all  of  the  needed  functionality  in  an  OS,  protocol,  and  transport  independent  manner.  A 
network  adapter  metalanguage  defines  services  to  support  network  addressing,  network  control 
operations  such  as  hardware  MAC  address  registration,  connection  oriented  operations,  and 
connectionless  operations. 

3.8.12.16.1  Standards.  Table  3.8-94  presents  standards  for  network  adapter  metalanguage. 


TABLE  3.8-94  Network  adapter  metalanguage  standards 
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3.8.12.16.2  Alternative  specification.  UNIX  System  V  (SVID)  based  operating  systems  defme  a 
STREAMS  interface  among  network  protocol  layer  drivers.  The  STREAMS  Data  Link  Provider 
Interface  (DLPI)  forms  the  basis  for  this  UD1  metalanguage. 

3.8.12.16  J  Standard  deficiencies.  None  currently  identified  for  this  service  area. 

3.8.12.16.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8. 12. 16 .5  Related  standards.  The  following  standards  are  related  to  device  driver  network 
adapter  metalanguage  standards: 

a.  IEEE  P1003.1g:  POSIX  Protocol  Independent  Network  Interface 

b.  IEEE  Std.  802.*:  Numerous  IEEE  standards  for  network  access  methods 

c.  IEEE  Std.  1596: 1992:  Scalable  Coherent  Interface 

3.8.12.16.6  Recommendations.  UDI  is  recommended  because  it  defines  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.17  Pointer  metalanguage.  Drivers  for  the  class  of  pointer  devices  have  the  need  to 
process  and  communicate  1, 2,  or  3  dimensional  position  information  and  state  changes  of  up  to  4 
buttons  to  the  higher  level  driver  (or  the  application,  via  the  portable  driver  environment).  Upon 
initial  binding,  the  driver  must  disclose  the  number  of  buttons  and  number  of  dimensions.  In 
normal  operation,  the  driver  must  report  position  and  button  status  asynchronously  whenever  r  ne 
of  these  changes.  A  pointer  metalanguage  defines  service  interfaces  for  binding  and  unbinding  to 
the  pointer  device  driver,  and  for  the  device  driver  to  asynchronously  notify  a  higher  level 
whenever  the  pointer  device  state  changes. 

3.8.12.17.1  Standards.  Table  3.8-95  presents  standards  for  pointer  metalanguage. 


TABLE  3.8-95  Pointer  metalanguage  standards 
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3.8.12.17.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  arc  available. 
3X12.17 3  Standard  deficiencies.  None  currently  identified  for  this  service  area. 

3.8.12.17.4  Portability  caveats.  Insufficient  UD1  usage  base  to  assess. 

3.8. 12. 17 £  Related  standards.  None  for  this  service  area. 

3.8.12.17.6  Recommendations.  UDI  is  recommended  because  it  defines  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.18  Storage  metalanguage.  Drivers  for  the  class  of  mass  storage  devices  need  to  deal  with 
the  random  access,  block  oriented  storage  characteristics  of  such  devices,  and  the  fact  that  such 
devices  often  have  internal  buffers  and  smart  controllers  which  can  re-order  I/O  operations  to 
optimize  performance.  A  storage  metalanguages  defines  service  interfaces  (as  yet  unspecified) 
which  support  the  unique  capabilities  of  this  class  of  devices. 

3.8.12.18.1  Standards.  Table  3.8-96  presents  standards  for  storage  metalanguage. 


TABLE  3.8-96  Storage  metalanguage  standards 
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3.8.12.18.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8. 12. 18  J  Standard  deficiencies.  A  storage  metalanguage  is  not  yet  included  in  the  UDI 
specification. 

3.8.12.18.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8. 12.  idii  Related  standards.  The  following  standard  is  related  to  device  driver  storage 
metalanguage  standards: 

a.  IEEE  P1285:  Draft  Standard  for  Scalable  Storage  Interface  (S2I) 

3.8.12.18.6  Recommendations.  UDI  is  recommended  because  it  will  define  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.19  Framework  for  custom  metalang^  ges.  Standard  metalanguages  address  the  specific 
capabilities  of  the  most  common  device  classes,  and  the  communication  among  commonly  stacked 
drivers.  Device  vendors  and  system  developers  will  always  be  defining  new  device  classes  and 
intra-driver  protocols,  for  which  no  standard  metalanguage  will  suffice.  Just  as  with  the 
contentious  POSIX  issue  of  application  level  APIs  for  control  of  arbitrary  devices,  a  device  driver 
standard  must  provide  a  framework  by  which  custom  metalanguages  can  be  integrated  into  the 
environment,  even  though  the  specific  interfaces  and  arguments  cannot  be  predicted  when  the 
environment  is  built.  A  framework  for  custom  metalanguages  provides  the  extensibility  necessary 
so  that  new  and  unusual  devices  and  protocols,  with  unique  command,  acknowledgment,  and 
statu-  er  uirements,  can  be  supported;  ultimately,  such  custom  metalanguages  may  be  transitioned 
to  sti.  id  metalanguages  based  on  their  widespread  adoption. 

3.8.12.19.1  Standards.  Table  3.8-97  presents  standards  for  framework  for  custom 
metalanguages. 


TABLE  3.8-97  Framework  for  custom  metalanguages  standards 
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3. 8. 12., 9.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.12.19.3  Standard  deficiencies.  A  framework  for  custom  metalanguages  is  not  yet  included  in 
the  UDI  specification. 

3.8.12.19.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.C.12.19.5  Related  standards.  The  following  standard  is  related  to  device  driver  framework  for 
custom  metalanguage  standards: 

a.  IEEE  P1003.  Id:  Realtime  Amendment  to  POSIX  (device  control) 

3.8. 12. 19.6  Recommendations.  UDI  is  recommended  because  it  will  define  such  a  framework, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.8.12.20  Versioning.  Drivers  must  irdicate  the  version  of  a  standard  to  which  they  conform,  so 
that  the  environment  can  enforce  conformance  to  the  specific  set  of  interfaces  documented  in  the 
appropriate  standard.  The  environment  must  be  able  to  simultaneously  support  drivers  which 
conform  to  multiple  versions  of  the  standard.  Versioning  services  provide  the  necessary  interfaces 
for  the  environment  to  query  a  driver  for  the  version  to  which  it  conforms. 

3.8.12.20.1  Standards.  Table  3.8-98  presents  standards  for  versioning. 


TAELE  3.8-98  Versioning  standards 
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3.8.12.20.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.12.20.3  Standard  deficiencies.  Versioning  capabilities  are  not  yet  included  in  the  UDI 
specification. 

3.8.12.20.4  Portability  caveats.  Insufficient  UDI  usage  b,ase  to  assess. 

3.8.12.20.5  Related  standards.  None  for  this  service  area. 

3.8.12.20.0  Recommendations.  UDI  is  recommended  because  it  will  define  these  interfaces, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 


April  7,  1997 


3.8-187 


Version  3. 1 


Information  Technology  Standards  Guidance 


Operating  System  Services 


3Ji.I2.21  Packaging  and  distribution  format.  To  achieve  driver  portability  without  requiring 
that  driver  vendors  distribute  source  code,  a  driver  binary  must  be  built  from  source  code 
conforming  to  the  interface  standards,  and  written  onto  media  in  some  common  distribution 
format  The  environment  must  be  able  to  link  with  these  binaries.  Packaging  and  distribution 
format  standards  should  support  multiple  media  format  types  to  allow  for  systems  which  do  not 
support  particular  media  types,  multiple  drivers  on  a  particular  piece  of  media,  and  well-accepted 
common  formats  across  all  media  types. 

3.8.12 .21.1  Standards.  Table  3.8-99  presents  standards  for  packaging  and  distribution  format. 


TABLE  3^8-99  Packaging  and  distribution  format  standards 
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3.8.12.21.2  Alternative  specification.  No  other  consortia  or  de  facto  specifications  are  available. 

3.8.12.21.3  Standard  deficiencies.  Packaging  and  distribution  formats  are  not  yet  included  in  the 
UDI  specification. 

3.8.12.21.4  Portability  caveats.  Insufficient  UDI  usage  base  to  assess. 

3.8.12.21.5  Related  standards.  None  fer  this  service  area. 

3.8.12.21.6  Recommendations.  UDI  is  recommended  because  it  will  define  these  formats, 
promises  to  be  an  open-systems  solution  to  a  major  software  portability  problem,  and  is  being 
developed  by,  and  backed  by,  a  substantial  portion  of  the  computer  industry. 
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3.9  System  management  services.  Centralized  system  management  services  refer  to  services 
that  allow  systems  and/or  enterprises  to  be  managed  from  a  single,  centralized  point.  Distributed 
system  management  services  refer  to  services  that  allow  systems  and/or  enterprises  to  be  managed 
from  any  node  in  the  enterprise,  in  a  variety  of  ways.  In  some  cases  an  enterprise  may  be 
managed  as  a  single  unit,  but  management  tasks  can  be  performed  at  any  node.  In  other  cases,  the 
enterprise  may  be  split  into  multiple  domains,  each  having  its  own  management  system,  but  the 
different  management  systems  can  cooperate  with  each  other  and  exchange  and  use  each  others' 
management  information. 

3.9.1  State  management.  This  requirement  states  the  need  for  a  mechanism  that  initializes  the 
system  or  components  of  the  system,  to  a  pre-determined  state  where  it  can  operate  in  the 
distributed  environment.  Also  required  is  the  ability  to  shutdown  all  or  part  of  the  system 
gracefully  for  maintenance,  security,  or  component  upgrade  reasons.  Complementing  startup,  the 
ability  to  suspend,  synchronize,  or  shutdown  is  also  required.  A  less  invasive  mechanism  of 
enroll/disenroll  is  needed  to  allow  a  component  to  be  recognized  or  excluded  from  the  distributed 
system  while  not  directly  affecting  its  operation. 

3.9.1.1  Independent  window  management  services.  (This  BSA  appears  both  in  part  3  and  part 
9.)  Window  management  services  are  a  necessary  part  of  any  windows  system  to  perform 
functions  such  as  resizing  or  moving  windows.  These  services  are  not  to  be  confused  with 
services  managing  individual  windows  as  though  they  were  separate  terminals. 

3.9.1.1.1  Standards.  Table  3.9-1  presents  standards  for  independent  window  management 
services. 


TABLE  3.9-1  Independent  window  management  services  standards 


1  Standard 
|  Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

IEEE 

Modular  Toolkit  Environment  (MTE) 

1295:1993 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  1.2 

Informational 

(Approved) 

CPC 

MITX 

Consortium 

X  Window  System  (Tab  Window  Manager) 

X11R5 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

lnfoimotional 

(Approved) 

Motif  1 .2  is  the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and 
programming  and  data  interfaces.  XI 1R5  is  the  current  release  of  Version  1 1  of  the  X  Windows 
GUI  standard.  The  IBM  Presentation  Manager  is  included  to  support  legacy  systems. 

3.9.1. 1.2  Alternative  specifications.  The  following  specifications  are  also  available  for  legacy 
support: 


a.  APIW 
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b.  USL/Sun  Open  Look  Windows  Manager  (oiwm) 

c.  IBM  SAA  Presentation  Manager  Window  Manager. 

3.9.1. U  Standards  deficiencies.  Although  all  window  managers  perform  functions  such  as 
window  resizing  and  moving  (window  manipulation),  some  do  not  manage  their  windows 
independently,  as  if  each  window  were  a  separate  system.  Failure  to  manage  windows 
independently  may  create  situations  in  which  an  application  seizing  in  one  window  may  propagate 
the  errors  to  other  windows  causing  them  to  seize  (lock  up).  In  addition,  without  an  independent 
window  manager,  usually  it  is  not  possible  to  invoke  programs  that  run  in  graphical  mode  at  the 
same  time  (but  in  different  windows  on  the  same  screen)  as  programs  running  in  character  mode. 
Certain  windows  systems  running  under  single-tasking  DOS  also  do  not  support  independent 
window  managers. 

Motif  2.0  is  somewhat  incompatible  with  the  multi-threading  implementation  in  XI 1R6. 

As  no  significant  products  are  as  yet  available  for  Motif  2.0,  the  previous  version,  Motif  1.2, 
remains  as  the  reference  standard.  Adoption  of  Motif  2.0  will  be  delayed  until  an  appropriate 
threshold  of  Motif  2.0  products  are  available  and  until  resolution  of  potential  conflicts  between 
Motif  2.0  and  XI 1R6. 

3.9.1.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.1. 1.5  Related  standards.  No  standards  are  related  to  independent  window  management 
standards. 

3.9.1. 1.6  Recommendations.  A  procurement  should  specify  a  Windows  Manager  that 
accommodates  window  manipulation  and  application  seizure  protection.  Windows  systems  using 
X  Windows  operating  on  protected  operating  systems  like  UNIX  are  more  robust  (i.e.,  the  failure 
of  one  application  will  not  cause  other  applications  to  fail  automatically)  than  some  running  on  the 
unprotected  DOS  operating  system. 
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3.9.1.2  System  startup  and  shutdown.  System  startup  and  shutdown  refers  to  a  standardized 
method  for  starting  up  and  gracefully  shutting  down  a  system  without  losing  or  corrupting  data  or 
code,  and  in  the  case  of  a  multiuser  system,  giving  users  advance  notification  of  the  shutdown  so 
that  they  can  save  their  files  and  log  off  the  system  in  time. 

3.9.1.2.1  Standards.  Table  3.9-2  presents  standards  for  system  startup  and  shutdown. 


TABLE  3.9-2  System  startup  and  shutdown  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IB 

■ 

*" 

hots,  is 

3.9. 1.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  BSD  4.3  UNIX. 

b.  System  V  Release  4. 

3.9. 1.2 3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9. 1.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9. 1.2.5  Related  standards.  No  standards  are  related  to '  /stem  startup  and  shutdown  standards. 

3.9.1.2.6  Recommendations.  No  specific  standards  are  recommended  at  this  time. 
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3.9.L3  Batch  scheduling.  (This  BSA  appears  both  in  part  8  and  part  9.)  Batch  scheduling  refers 
to  the  ability  to  submit  jobs  to  be  executed  when  the  system  load  permits.  The  "at"  command 
allows  jobs  to  be  executed  at  a  predefined  time.  Batch  queuing  refers  to  the  ability  to  place 
multiple  jobs  in  a  queue  for  processing,  and  to  access  and  manage  the  queue. 

3.9.1.3.1  Standards.  Table  3.9-3  presents  standards  for  batch  scheduling. 


TABLE  3.9-3  Batch  scheduling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Information  Technology  -  Portable  Operating  Sy stem 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (u  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

NPC 

mPF 

Portable  Operating  System  Interface  (POSIX)  -  Part  2:Shell 
and  Utilities  •  Amendment  1:  Batch  Environment 

I003.2d:  1994 

Mandated 

(Approved) 

CPC 

X/Op en 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Utilities,  Issue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  1 5:  Scheduling  Function 

10164-15:1995 

Informational 

(Approved) 

CPC 

OSF 

GSF/1  Operating  System 

OSF/1  O.S. 

Informational 

(Approved) 

3.9.1 .3.2  Alternative  specifications.  The  Berkeley  BSD  4.3  Unix  "at"  and  "batch"  commands  are 
also  available. 

3.9.I.3 3  Standards  deficiencies.  The  POSIX.2  and  Unix  "at"  and  "batch"  commands  are 
designed  for  a  single  machine,  centralized  environment  Traditional  POSIX  and  Unix  batch 
capabilities,  such  as  "at"  and  "batch,"  are  inadequate  and  inefficient  for  managing  resources  and 
scheduling  jobs  in  many  environments,  particularly  environments  that  manage  expensive 
resources,  because  they  are  very  limited.  For  example,  "at"  allows  users  only  to  schedule 
machines  to  run  jobs  at  particular  times.  No  Ada  bindings  exist  for  the  POSIX.2d  Batch  Queuing 
Extensions. 

3.9.1.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9. 1.3.5  Related  standards.  No  standards  are  related  to  batch  scheduling. 

3.9.1.3.6  Recommendations.  The  mandated  standards  are  recommended,  but  both  provide  only 
limited  batch  functionality.  For  international  work,  use  the  POS1X.2  standard's  new  "-t  time" 
option  for  the  "at"  command  to  express  a  time  for  execution  of  the  submitted  job  in  a  way  to 
support  other  time  conventions  more  easily. 
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3.9.1.4  Process  management  and  core  operating  system  services.  (This  BSA  appears  in  both 
part  8  and  part  9.)  Core  operating  system  services  are  basic  operating  system  services  and 
interfaces,  including  traditional  process  management,  memory  management,  time  services, 
scheduling,  terminal  handling,  error  and  exception  management  services,  file-oriented  services, 
and  generalized  input  and  output 

3.9.1.4.1  Standards.  Table  3.9-4  presents  standards  for  process  management  and  core  operating 
system  services. 


TABLE  3.9-4  Process  manaeement  and  core  ODeratine  system  services  standards 


Standard  Sponsor  Standard  Standard 

Type  Reference 


Portable  Operating  System  Interface  (POSDQ  Put  I : 
System  API  (Replace*  ISO  9945- 1 : 1990  and  incorporate* 
IEEE  1003,1b.  1003.1c.  and  1003.1i) _ 


Window  Management  and  Graphic*  Device  Interface, 
Volume  1  Microsoft  Win32  Programmer*  Reference 

Manual.  1993.  Microsoft  Press  _ 


Single  Unix  Specification  (Spec.  1 170),  System  Interface* 
and  Header*,  Issue  4,  Version  2.  (Part  of  XPG4) 


Single  Unix  Specification  (Spec.  1 170),  Sy*tem  Interface 
Definitions,  Issue  4,  Version  2  (part  of  XPG4) 


Portable  Operating  System  Interface  (POSDQ  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 
1:  Realtime  Extension  (C  language) 


POSIX  Part  1 :  System  Application  Program  Interface 
(API)  Amendment  2:  Thread*  Extension  [C  Language! 


POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  IC  Language  | 


Te*t  Method*  for  Measuring  Conformance  to  POSIX  - 
System  Interfaces 


Portable  Operating  System  Interface  (POSDQ  -  System 
Application  Program  Interface/  C  Language  (adopt* 
ISO/IEC  9945-1:1990) 


Syraum  V  interface  CSVID)  (raotaoed  by 

:  :  UNIX  Sj»d5<»ik.  (Spec.  liWfc 


April  7,  1997 


3.9-5 


Version  3. 1 


Information  Technology  Standards  Guidance 


System  Management  Services 


3.9. 1.4.2  Alternative  specifications.  Other  consortia  or  de  facto  alternative  specifications  (such 
as  ECMA  APIW)  for  the  Portable  Operating  System  Interface  for  Computer  Environments 
(POSIX)  standard  P1003.1  are  available. 

3.9.1. 4 Jt  Standards  deficiencies.  ISO  9945-1:1996  incorporated  IEEE  1003.1b  Realtime  and 
IEEE  1003.1c  Threads.  This  resolves  some  of  the  deficiencies  in  the  original  POSIX.  1,  but  the 
following  deficiencies  remain  in  the  available  standards: 

a.  Lacks  batch  scheduling  for  distributed  computing. 

b.  Has  weak  event,  error,  and  exception  management  services. 

c.  Has  weak  or  no  generalized  I/O  device  driver  services. 

d.  Has  reentry  problems  when  used  for  multiprocessing. 

e.  Reliability  and  maintainability  not  reflected  in  the  standard. 

f.  The  tasking  model  on  which  Ada  is  based  does  not  map  well  to  the  process  model 
on  which  POSIX.  1  is  based. 

g.  Has  tape  handling  facilities  requiring  long  backup  times. 

3.9. 1.4.4  Portability  caveats.  Different  specifications  and  implementations  conforming  with 
POSIX  (e.g.,  OSF/1,  SVID,  SVR4,  X/Open,  and  vendor  products)  often  support  the  same 
function,  but  support  them  slightly  differently.  For  example,  the  names  of  system  calls  may  be 
identical,  but  unanticipated  incompatibilities  will  arise  because  of  differences  in  the  data  types  of 
the  function,  the  data  types  of  the  arguments,  the  return  values,  the  required  header  files,  and  the 
symbolic  error  values. 

Implementations  conforming  with  POSIX  may  require  extra  header  files  for  function  calls  that  are 
ported  from  a  system  not  requiring  header  files  to  another  requiring  header  files.  Although  the 
impact  of  requiring  extra  header  files  is  not  always  clear,  differences  in  header  file  requirements 
can  reduce  portability.  For  example,  if  a  program  is  ported  from  a  system  not  requiring  a  header 
file  for  a  particular  function  call,  to  a  system  requiring  it,  the  call  to  that  function  may  be 
undefined  and  generate  an  error  message  about  the  nonexistent  header  file. 

Differences  within  header  files  can  reduce  portability  when  moving  from  a  system  that  does  not 
require  a  header  file  to  one  that  does.  For  example,  a  header  file  may  define  attributes  like  data 
types  or  symbols  conflicting  with  locally  defined  symbols. 

Implementations  of  systems  conforming  with  POSIX  may  refer  to  devices  by  logical  names, 
numeric  indicators,  data  structures,  or  pointers.  Superset  functions  in  implementations 
conforming  with  POSIX  are  important  to  have  and  convenient  to  use,  but  they  reduce  portability 
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The  meaning  of  ownership  of  "symbolic  links"  is  not  clear  or  consistent  across  different  systems. 
Only  the  meaning  of  owning  a  file  is  consistent 

Many  system  attributes,  such  as  system  limits  and  configuration  values  limits,  are  defined  by 
implementation . 

3.9.1.45  Related  standards.  The  following  standards  are  related  to  process  management  and 
core  operating  system  services  or  their  stand  is: 

a.  IEEE  1003.2: 1992:  POSIX  -  Shell  and  Utilities. 

b.  IEEE  1003.2a:  1992  POSIX  -  User  Portability  Extension. 

c.  IEEE  P1003.1e:  POSIX  -  Security  Interface  Extensions. 

d.  IEEE  P1003.21:  POSIX  -  Real  Time  Distributed  Systems  Communications. 

<.  X/Open  Common  Desktop  Environment  (XCDE)  -  Definitions  and  Infrastructure. 

3.9.1.4.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:1995,  and  IEEE  1003.1i:1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  IEEE  1003.1b  (section  3)  standardized  additional  functions  not  in  9945-1:1990  such  as 
memory  management  and  clocks  and  timers.  Federal  Information  Processing  Standard  (FIPS) 
151-2  should  also  be  consulted.  It  adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996 
version.  It  specifies  many  of  the  implementation-defined  system  limits  related  to  files  and 
directories  and  input/output. 

To  ensure  maximum  portability  and  smooth  running  information  processing  functions,  it  is 
important  to  determine,  at  a  detailed  level  (e.g.,  arguments,  order  of  the  arguments,  data  types  of 
the  function  and  arguments,  return  values,  symbolic  error  numbers),  the  specific  areas  of 
incompatibility  between  POSIX  and  the  systems  bid  by  vendors. 

To  ensure  that  no  harm  will  result  if  an  application  is  ported  from  a  system  that  requires  and 
supports  a  header  file  to  a  system  that  does  not  require  the  "include"  statement  in  the  system  call, 
remove  the  header  file  from  the  appliotion. 

Avoid  the  use  of  extensions  to  POSIX.  However,  if  extensions  to  POSIX  must  be  used  (they  may 
be  convenient),  the  applications  in  which  they  are  used  must  be  designed  carefully  for  portability 
(e.g.,  separate  the  portable  from  the  nonportable  code,  carefully  document  all  nonportable  code). 

Including  those  header  _J.es  required  by  POSIX.  1  will  ensure  that  properly  written  programs  will 
build  successfully  on  all  FIPS-certified  POSIX.  1 ,  regardless  of  which  header  files  may  be  optional 
on  a  given  vendor's  platform. 

Specifying  that  systems  must  conform  to  the  X/Open's  Single  Unix  Specification  as  demonstrated 
by  a  current  X/Open  Branding  Certificate  will  eliminate  the  portability  problems  identified  in  the 
first  paragraph  of  the  portability  caveats  section. 
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3.9. 1-5  System  administration  and  management  APIs.  (This  BSA  appears  in  part  8  and  part 
9.)  Operating  system-based  system  administration  standards  provide  interfaces  to  traditional, 
centralized  operating  system  administration  services  and  utilities.  System  management  APIs  refer 
to  standardized  Application  Programming  Interfaces  that  can  be  used  by  system  and  network 
managers  and  application  developers  to  manage  a  system  or  network.  They  also  are  used  to 
develop  a  system  or  network  management  application,  without  having  to  resort  to  writing  third- 
ger  oration  language  code  or  UNIX/POSIX  shell  scripts  to  perform  the  same  functions  on 
different  machines.  In  this  sense,  system  and  network  management  APIs  are  considered 
productivity  tools  for  system  managers  and  system  management  application  developers. 

3.9.1.5.1  Standards.  Table  3.9-5  presents  standards  for  system  administration  and  management 
APIs. 


TABLE  3.9-5  System  administration  and  management  APIs  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Management  Piotocol  Profile*  (XMPP) 

C206  (11/93) 

Adopted 

(Approved) 

CPC 

NMF 

OMNTPoint  1  (Adapt*  ISO  Profile  Sets  1 1 183-X.  12059- 
X,  and  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

NPC 

rPKR 

Open  Syitem*  Interconnection  (OSI)  Abrtract  Data 
Manipulation  -  Application  Program  Interface  (API) 
(Language  Independent) 

1224:1993 

Adopted 

(Approved) 

NPC 

IFEP 

POSK  Sy item  Administration  -  Part  2:  Software 
Administration  (former  P1003.7.2) 

1387.2:1995 

Informational 

(Approved) 

NPC 

IEEE 

POSIX:  Syitem  Adm  initiation  -  Part  3:  Uier  and  Group 
Administration 

1387.3:1996 

Informational 

(Approved) 
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3.9. 1.5.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Groupe  Bull:  Consolidated  Management  Architecture  (CMA),  on  which  X/Open's 
XMP  and  OSF's  CM-API  are  based. 

b.  Tivoli  Systems:  Objcall  API,  which  is  incorporated  in  MRB  which  is  based  on 
Tivoli.  NOTE:  A  high-level  API,  such  as  the  Tivoli  Systems'  "objcall"  API  is  more 
suiied  for  application  development  and  integration  than  for  management  tasks  such 
as  long-term  monitoring  of  system  devices. 

c.  Tivoli  Systems:  Application  Programming  Interface  (API)  to  objects. 
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d.  Berkeley  Unix. 

e.  OSF:  OSF/1. 

Standards  deficiencies.  All  traditional  Unix  system  administration  is  difficult  Neither 
System  V  system  administration  facilities  nor  Berkeley  Unix  system  administration  facilities  were 
designed  for  a  distributed  networked  environment  Traditional  Unix  system  administration  is  not 
object-based  and  is  not  easily  extendable. 

3.9.1.5.4  Portability  caveats.  The  traditional  AT&T/USL  system  administration  facilities  are 
largely  different  from  and  incompatible  with  the  traditional  Berkeley  Unix  system  administration 
facilities. 

UI  specifies  the  AT&T/USL  system  administration  for  the  SVID.  OSF  provides  the  Berkeley 
Unix  system  administration  facilities  for  OSF/1,  except  for  the  System  V  accounting  facilities.  The 
SVID  and  OSF/1  system  administration  interfaces,  configuration  files,  and  procedures  are 
incompatible.  Most  of  the  shell  scripts  written  for  SVID-based  Unix  will  not  be  portable  to 
OSF/1  systems.  The  many  system  administration  configuration  files  required  by  POSIX  and  Unix 
are  not  portable  across  different  machines. 

3.9. 1.5.5  Related  standards.  The  following  standards  are  related  to  traditional  operating  system 
administration: 


a.  ISO  IS  9595/9596/CCirr  X.7 10/7 1 1 :  CMIS/CMIP  (Common  Management 
Information  Service/Protocol). 

b.  ISO  IS  7498:1986/CCITT  X.700:  Management  Framework. 

c.  ISO  IS  10040:1991:  Systems  Management  Overview. 

d.  ISO  IS  10164-1:1993/CCITT  X.730:  Object  Management  Function. 

e.  ISO  IS  10164-2:1993/CCITT  X.731:  State  Management  Function. 

f.  ISO  IS  10164-3:1993/CCITT  X.732:  Attributes  for  Representing  Relationships. 

g.  ISO  IS  101 64-4: 1992/CCITT  X.733:  Alarm  Reporting  Function. 

h.  ISO  IS  10164-5:1993/CCITT  X.734:  Event  Report  Management  Function. 

i.  ISO  IS  10164-6: 1993:Log  Control  Function. 

j.  ISO  IS  10 164-7: 1992/CCITT  X.736:  Security  Alarm  Reporting  Function. 

k.  ISO  IS  10164-8:1993  Security  Audit  Trail  Function. 
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L  ISO  IS  10164-12:1994  Test  Management  Function. 

m.  ISO  IS  10165-1:1993/CCITT  X.720:  Structure  of  Management  Information. 

n.  ISO  IS  10165-2:1992/CCITT  X.721:  Definition  of  Management  Information. 

o.  ISO  IS  10 165-4: 1992/CCnT  X.722:  Guidelines  for  the  Definition  of  Managed 
Objects 

p.  ISO  DIS  10181-2.2:1993:  Authentication  Framework. 

q.  ISO  8824:1990:  (Edition  2)  Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

r.  ISO  8825: 1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1  (BER). 

s.  NIST  FIPS  146-2:  POSIT  (for  ASN.l  and  BER  (related  to  ISO  8824  and  8825)). 

t.  NIST  FIPS  158-1:  X  Window  System  (XI 1  Version  5). 

u.  NIST  FIPS  179-1:  Government  Network  Management  Profile  (GNMP). 

v.  IEEE  P1003.  le:  Security  Interface  Standards  for  POSIX. 

w.  X/Open:  G207:9/93:  Systems  Management  Reference  Model 

x.  X/Open:  G303:9/93:  Systems  Management:  Managed  Object  Guide  (XMOG). 

3.9.1.5.6  Recommendations.  The  PM  should  plan  to  use  X/Open’s  XMPP  as  a  common  API  to 
CMIP  and  SNMP.  X/Open,  Unix  International,  and  OSF  specify  the  same  API,  although  they  call 
them  by  different  names  (XMP  and  CM-API).  The  XMP  and  CM-API  hide  some  of  the 
differences  between  CMIP  and  SNMP  and  eliminate  the  need  to  learn  two  different  syntaxes  to 
access  both  protocols. 

The  OMNIPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
Version  3.0  of  the  NIST  Application  Portability  Profile. 
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3.9.1.6  Scheduling.  (This  BSA  appears  both  in  part  8  and  part  9.)  Scheduling  services  and 
interfaces  provide  different  scheduling  policies,  such  as  time-sharing,  priority-based,  and  user- 
defined.  Scheduling  services  initiate  and  terminate  jobs  (programs)  in  the  computer,  maintain  a 
list  of  jobs  to  be  run,  and  allocate  computer  resources  depending  on  priority.  Each  process  is 
controlled  by  an  associated  scheduling  policy  and  priority. 

Priority  and  preemptive  scheduling  standards  provide  interfaces  to  scheduling  services  allowing 
the  highest-priority  process  to  run  first  and  to  completion.  Preemptive  multitasking  shares 
processing  time  with  all  running  programs.  For  example,  background  programs  can  be  given 
recurrent  CPU  time  no  matter  how  heavy  the  foreground  load.  Priority  bumping  is  the  process 
during  a  link,  trunk,  or  facility  failure  where  lower  priority  user  access  to  network  services  is 
interrupted  to  offer  those  services  or  bandwidth  to  a  predesignated  higher  priority  user. 

3.9.1.6.1  Standards.  Table  3.9-6  presents  standards  for  scheduling. 


TABLE  3.9-6  Scheduling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (POSIX)  Part  1 : 
System  API  Replaces  ISO  9945-1 : 1990  and  incorporates 
IEEE  1003.1b.  1003.1c,  and  1003.  li) 

9945.1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmed'  Reference 
Manual,  1993,  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

NPC 

ILRk 

Portable  Operating  System  Interface  (POSIX)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1 :  Realtime  Extension  (C  language) 

1003.1b:1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  [C  Language! 

1003.  li:  1995 

Informational 

(Approved) 

GPC 

NIST 

Informational 

(Approved) 
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3.9.1.6.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.9.1.6.3  Standards  deficiencies.  The  POSIX.l  standard  is  not  suitable  for  real  time  applications, 
because  it  supports  only  time-sliced  time-sharing  scheduling  and  does  not  allow  scheduling  based 
on  the  priority  of  a  process. 
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The  POSIX  "nice"  command  for  adjusting  process  priorities  is  not  suitable  for  real  time 
applications,  because  the  "nice"  function  is  merely  a  request  to  the  operating  system  to  favor  a 
particular  process  for  scheduling.  However,  in  traditional  Unix  and  POSIX.  1,  the  effect  of  the 
"nice"  command  is  tempered  by  degrading  priorities  based  on  CPU  usage.  In  addition,  the  "nice" 
interface  specifies  an  adjustment  to  a  "nice"  value,  rather  than  setting  it  to  an  explicit  value.  Real 
time  applications  usually  want  to  set  priority  to  an  explicit  value.  Finally,  "nice()"  does  not  allow 
for  changing  the  priority  of  another  process. 

POSIX.  1  scheduling  is  not  based  on  absolute  priorities.  A  process's  scheduling  priority  degrades 
as  it  runs.  POSIX.1  does  not  allow  a  system  operator  or  real  time  application  developer  to  tailor 
process  scheduling. 

POSIX.lb  does  not  address  the  priorities  of  "system"  processes.  If  system  processes  are  not 
running  in  low  priority  ranges,  conflicts  with  real  time  processes  could  result 

POSIX.  1  b  does  not  address  the  interaction  between  priority  and  swapping  because  swapping  and 
virtual  memory  paging-related  issues  are  extremely  dependent  on  the  implementation  and  nearly 
impossible  to  standardize.  However,  the  POSIX.  1  b  scheduling  paradigm  fully  describes  the 
scheduling  behavior  of  runnable  processes,  including  the  requirement  for  the  working  set  to  be 
resident  in  memory. 

POSIX.lb  does  not  address  the  temporary  lending  of  priority  from  one  process  to  another  by  the 
system  (e.g.,  for  the  purposes  of  affecting  the  freeing  of  resources). 

POSIX.  1  b  does  not  define  the  effect  of  I/O  interruptions  and  other  system  processing  activities 
because  the  effect  of  I/O  interruptions  and  system  loading  is  intrinsically  nondeterministic. 

Influence  levels  (restrictions  on  a  process's  ability  to  affect  other  processes  beyond  a  certain  level) 
are  defined  by  the  implementation. 

POSIX.  lb  does  not  address  the  mechanisms  used  to  control  access  to  scheduling  facilities. 

POSIX.  1  b  does  not  address  whether  a  process'  handling  of  an  event  with  a  higher  priority  should 
have  its  priority  boosted.  This  may  be  addressed  later. 

POSIX.  lb  provides  a  minimum  of  32  priority  levels.  While  this  number  conforms  to  the  currently 
accepted  scheduling  theory  requiring  at  least  32  priority  levels  for  predictable  responses  with 
acceptable  processor  utilization,  it  is  less  than  the  256  priority  levels  that  many  real  time  systems 
need. 

3.9.1.6.4  Portability  caveats.  POSIX. lb  supports  a  time-sharing  scheduling  policy,  a  real  time 
scheduling  policy,  and  a  user-defined  scheduling  policy,  but  does  not  define  the  default  scheduling 
policy.  This  could  cause  problems  in  porting  the  scheduling,  and  as  a  result,  could  cause 
problems  in  the  response  time  behavior  of  real  time  applications. 
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POSDC.  lb  does  not  address  resource  preemption.  The  lack  of  resource  preemption 
standardization  could  affect  the  ability  to  port  real  time  applications  so  that  they  maintain  the 
same  behavior  between  systems.  However,  this  does  not  affect  source  code  portability,  because 
resource  preemption  functions  lie  underneath  the  POSIX.lb  interface. 

The  POSIX.lb  priority-based  scheduling  functions  are  incompatible  with  the  System  V.4  SVID 
and  SVR4  real  time  extensions'  priority  scheduling.  The  System  V.4  "priocntlO"  interface  for 
priority  scheduling  violates  POSIX,  lb  guidelines  since  it  uses  an  argument  to  define  the  system 
call  function.  This  increases  the  complexity  of  the  "priocntlO"  system  call  because  it  consolidates 
a  large  collection  of  related  but  logically  separate  functions  into  a  single  interface.  Also,  the 
"priocntlO"  interface  is  less  flexible  than  the  POSIX.  lb  interface,  because  "priocntlO"  does  not 
permit  separate  disjointed  or  overlapping  priority  ranges  between  policies. 

The  specification  of  only  32  priority  levels  could  reduce  the  behavior  of  some  applications  that 
depend  on  multiple  priority  let  els  to  have  reduced  portability  across  conforming  implementations. 

In  a  conforming  implementation,  the  priority  ranges  for  the  FIFO  and  Round  Robin  scheduling 
policies  (SCHED_FIFO  and  SCHED_RR)  defined  in  the  header  <sched.h>  must  be  allowed  to 
overlap,  because  these  scheduling  policies  are  identical  except  for  the  time  interval.  Because  the 
third  scheduling  policy  permitted  by  POSIX.  lb  (SCHED_OTHER)  is  defined  by  the  user  or 
implementation,  any  interactions  among  SCHED_OTHER  and  SCHED_FlFO  or  SCHED_RR 
also  is  defined  by  the  implementation.  Therefore,  any  application  that  depends  on  this  interaction 
is  not  a  strictly  conforming  application,  and  may  not  be  portable  across  all  systems. 

3.9.1.6 £  Related  standards.  The  following  standard  is  related  to  priority  and  preemptive 
scheduling  standards: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

3.9.1.6.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (1SO/IEC  9945-1:1990,  IEEE  1003. lb:  1 993. 
IEEE  1003.1c:1995,  and  IEEE  1003. li:  1 995)  are  all  incorporated  in  the  new  ISO/1EC  9945- 
1 : 1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should  also  be  consulted.  It 
adopted  ISO  9945-1:1990  and  is  still  applicable  to  the  1996  version.  IEEE  1003.1b  standardized 
additional  functions  not  in  the  original  POSIX.  1.  FIPS  151-2  specifies  many  of  the 
implementation-defined  system  limits  and  chooses  among  incompatible  POSIX  options. 

Each  real  time  functionality  in  the  POSIX.lb  standard  is  an  option.  If  procurements  do  not  call 
out  the  POSIX.lb  Execution  Scheduling  option  explicitly,  vendors  may  provide  a  system 
conforming  with  POSIX.lb  but  not  including  this  option. 

Procurements  should  require  implementations  to  document  the  priority  ranges  in  which  system 
processes  run  to  check  that  conflicts  will  not  exist  between  system  processes  and  real  time 
processes. 
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If  a  particular  default  scheduling  policy  is  desired,  a  procurement  should  either  specify  the  default 
explicitly  or  specify  the  ability  for  system  operators  to  define  one. 

System  processes  always  should  execute  in  low  priority  ranges  to  avoid  conflict  with  real  time 
processes. 

A  portable,  standardized  interface  for  locking  portions  of  a  process  in  memory  is  necessary  to 
ensure  that  paging  behavior  does  not  affect  the  scheduling  of  real  time  processes. 

An  organization-wide  standard  default  scheduling  policy  should  be  established.  Also,  applications 
should  make  no  assumptions  about  the  default  scheduling  policy. 

Although  the  POSDC.lb  real  time  standard  allows  source  code  portable  applications  to  be  written, 
it  does  not  guarantee  that  two  such  applications  can  coexist  in  a  single  system.  To  minimize 
conflicts,  developers  should  adhere  to  certain  programming  guidelines  to  document  the  intent, 
rather  than  the  syntax,  of  the  standardization  issues. 
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3.9.1.7  Subsystem  management  (This  BSA  appears  both  in  part  8  and  part  9.)  Subsystem 
Management  Service  (SMS)  is  a  product  that  controls  the  execution  of  system  processes  (usually 
daemons).  It  ensures  that  related  processes  are  started  (or  stopped)  in  the  proper  sequence.  It 
also  provides  a  standard  systems  administration  command  syntax  to  start/stop  these  processes, 
and  the  specification  for  an  RPC  interface  that  could  be  embedded  into  daemons  to  allow 
administrator  interaction.  Without  SMS,  the  commands  to  start  these  processes  are  embedded  in 
the  system  startup  file.  There  is  no  mechanism  to  ensure  that  one  daemon  is  ready  before  starting 
a  related  one.  To  stop  a  daemon,  the  administrator  needs  to  know  the  syntax  of  the  appropriate 
command,  and  needs  to  know  which  other  related  daemons  also  need  to  be  stopped.  If  a  daemon 
dies,  the  administrator  needs  to  know  which  related  processes  to  stop,  and  the  proper  sequence  to 
restart  them. 

3.9.1.7.1  Standards.  Table  3.9-7  presents  standards  for  subsystem  management 


TABLE  3.9-7  Subsystem  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 
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3.9. 1.7.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.9. 1.73  Standards  deficiencies.  There  are  no  products  currently  using  the  OSF  DME  SMS 
specifications.  The  software  available  from  the  OSF  could  be  used  as-is,  although  it  is  intended  to 
be  used  by  third-party  vendors  as  the  basis  for  products. 

There  are  also  no  daemons  that  implement  the  SMS  RPC  interface,  except  for  the  ones  that  come 
with  OSF  DME.  Therefore  the  SMS  is  required  to  use  Signals  to  stop  daemons,  which  may  have 
unpredictable  results  if  the  daemon  does  not  catch  the  signal  correctly. 

3.9. 1.7.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.1.7.5  Related  standards.  The  following  standard  is  related  to  subsystem  management, 
a.  OSF  DC.E  Remote  Procedure  Call  (RPC) 

3.9.1. /.6  Recommendations.  There  are  no  recommendations. 
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3.9.2  User  and  group  management.  This  requirement  states  the  need  to  establish  identity  by 
appropriate  authentication  means  for  a  user  prior  to  interaction  with  application  software, 
establishing  a  session  on  an  application  platform,  accessing  information  storage,  or  establishing 
communication.  Coupled  with  this  identification  is  the  association  of  privilege,  by  individual  or 
group  and  requisite  resource  authorization,  potentially  across  multiple  components  of  the  system. 

3.9.2.1  User/group  identification.  (This  BSA  appears  both  in  part  8  and  part  9.)  User/group 
identification  services  provide  traditional  system  administration  interfaces  for  administering  users 
and  groups.  These  services  are  mechanisms  for  system  and  network  administrators  to  use  when 
implementing  a  management  policy  across  a  system.  Administrators  can  use  the  services  to 
establish  domains  and  policies  for  management  throughout  the  system.  They  can  provide  the 
ability  for  applications  to  access  group  and  user  databases.  Users  can  set  up  their  own  areas  of 
management  and  policies  or  use  system  defaults  that  are  included  in  management  services. 

3.9.2.1.1  Standards.  Table  3.9-8  presents  standards  for  user/group  identification. 


TABLE  3.9-8  User/group  identification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecvde) 

IPC 

ISO/EC 

Portable  Operating  System  Interface  (POSIX)  Put  1: 
System  API  (Replaces  ISO  9945- 1 : 1990  and  incorporates 
IEEB  1003.1b.  1003.1c.  and  1003,li) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Micro  soft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmers'  Reference 
Manual,  1993,  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

NPC 

IF.PF- 

POSIX:  System  Administration  -  Part  3:  User  and  Group 
Administration 

1387.3:1996 

Emerging 

(Approved) 

NPC 

1KP.R 

Portable  Operating  System  Interface  (POSIX)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1;  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  Part  I:  System  Application  Program  Interface 
(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Extension  1C  Languagel 

1 003. 1  i:  1 995 

Informational 

(Approved) 

GPC 

NIST 

Computer  Security  Guidelines  for  Implementing  the 
Privacy  Act  of  1 974 

FIPS  PUB  41:1975 

Informational 
(Approved)  N 

GPC 

NIST 

Guidelines  on  Evaluation  of  Techniques  for  Automated 
Personal  Identification 

FIPS  PUB  48:1977 

Informational  U 
(Approved)  | 

3.9.2.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  Unix:  Centralized  User  and  Group  Management. 

b.  OSF/1  O.S.:  Centralized  User  and  Group  Management. 

3.9.2.1.3  Standards  deficiencies.  User  and  group  management  in  the  SVID,  OSF/1 .  and 
Berkeley  Unix  is  designed  for  a  centralized,  single  machine  environment.  No  Ada  bindings  exist 
for  user  and  group  management  standards. 
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3.9.2.1.4  Portability  caveats.  System  V  Unix  and  the  SVID  use  the  commands  "useradd"  and 
"groupadd"  to  add  a  new  user  or  group  to  the  system.  The  OSF  and  Berkeley  Unix  use  the 
commands  "adduser"  and  "addgroup"  to  do  the  same  thing. 

Although  the  functionality  defined  by  P1387.3  is  based  on  historical  user  and  group  administration 
practice,  no  commercial  products  which  conform  to  the  (draft)  standard  are  available  as  yet. 

3.9.2.15  Related  standards.  The  following  standards  are  related  to  user  and  group  management 
or  user  and  group  management  standards: 

a.  ISO/IEC  9595: 1991 :  CMIS. 

b.  ISO/IEC  9596: 1 99 1 :  CMIP. 

c.  ISOAEC  DIS  1 1578.2:  RPC. 

d.  Network  Management  Forum;  OMNIPoint  1. 

e.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

f.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

g.  Internet  RFC  1213:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

3.9.2.1.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.9.3  Configuration  control.  This  requirement  states  the  need  to  be  able  to  manage  the 
configuration  of  the  system.  This  entails  the  ability  to  view  the  current  configuration  statically 
and  dynamically  modify  the  configuration,  and  the  ability  to  tune  the  system. 

3.9.3.1  Software  distribution.  (This  BSA  appears  both  in  part  2  and  part  9.)  Software 
distribution  and  installation  services  comprise  utilities  for  packaging,  installing,  and  distributing 
software  for  use  on  heterogeneous  and  potentially  incompatible  systems.  These  services  will 
enable  network  managers  to  transmit  software  to  any  stand-alone  or  networked  system,  regardless 
of  the  media  used  for  distribution.  Standards  for  software  distribution  in  a  system  provide  a 
standardized  layout  for  distributing  and  installing  software  in  a  single  system  or  network.  They 
explicitly  define  each  phase  of  software  distribution,  installation,  and  configuration-covering  such 
distribution  media  as  disks,  tapes,  and  CD-ROM. 

3.9J.1.1  Standards.  Table  3.9-9  presents  standards  for  software  distribution. 


TABLE  3.9-9  Software  distribution  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

IEEE 

PGSIX  System  Administration  -  Put  2:  Software 
Administration  (former  P1003.7.2) 

1387.2:1995 

Adopted 

(Approved) 

CPC 

X/Op« 

Single  UNIX  Specification  (Spec.  1 170) 

T908:  1995 

Emerging 

(Approved) 

CPC 

X/Open 

Systems  Management:  Distributed  Software  Administration 
(XDSA) 

P429: 1997 

Informational 

(Approved) 

3.9.3.1.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Hewlett-Packard:  "swinstall"  and  "swpackage"  systems. 

b.  USG:  SVR4-based  "pkgadd"  system. 

c.  Santa  Cruz  Operation  (SCO):  "custom+"  system. 

3.9.3.1.3  Standards  deficiencies.  The  IEEE  1387.2  standard  does  not  provide  for  acting  upon 
log  files  in  remote  file  systems.  No  Ada  bindings  are  available  for  software  distribution  standards. 

3.9.3.1.4  Portability  caveats.  Although  the  IEEE  1387.2  standard  is  based  on  Hewlett-Packard's 
''swinstaU"  and  "swpackage"  systems,  the  standard  has  modified  the  specifications  so  that  they  are 
not  exactly  like  the  HP  systems. 

3.9.3.1.5  Related  standards.  The  following  standards  are  related  to  software  distribution  or 
software  distribution  standards: 

a.  ISO/IEC  JTC1  IS  9595:1991:  Common  Management  Information  Service 
(CMIS). 
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b.  ISO/IEC  JTC 1  IS  9596: 1991:  Common  Management  Information  Protocol 
(CM  IP). 

c.  ISO/IEC  IS  1 1578:  1996,  Information  Technology  -  Open  Systems 
Interconnection  -  Remote  Procedure  Call  (RPC). 

d.  Internet  RFC  1155  (STD  17):  Structure  and  Identification  of  Management 
Information  for  TCP/IP-based  Internets. 

e.  Internet  RFC  1 157  (STD  15):  A  Simple  Network  Management  Protocol. 

f.  Internet  RFC  1213  (STD  17):  Management  Information  Base  for  Network 
Management  of  TCP/IP-based  Internets  (MIB-II). 

g.  Network  Management  Forum:  OMNIPoint  1 . 

3.9.3.1.6  Recommendations.  IEEE  1387.2  is  recommended. 

A  new  version  of  the  X/Open  Single  UNIX  Specification  (Spec.  1 170)  is  expected  to  be  issued  in 
1997. 


April  7,  1997 


3.9-19 


Version  3.1 


Information  Technology  Standards  Guidance _ SjiSlan  Management  SCTYICM 

3.9 32  Software  configuration  management  (This  BSA  appears  both  in  part  2  and  part  9.) 
Configuration  management  is  the  process  of  applying  administrative  and  technical  procedures 
throughout  the  software  life  cycle  to  identity,  define,  and  baseline  configuration  items  for  software 
in  a  system;  control  modifications  and  releases  of  the  items;  record  and  report  the  status  of  the 
items  and  modification  requests;  ensure  the  completeness  and  correctness  of  the  items;  and 
control  storage,  handling,  and  delivery  of  the  items.  This  includes  activities  employed  by  the 
developer  to  identify  entities  (such  as  computer  files,  documents.  Computer  Software 
Configuration  Items)  whose  version  and  status  are  to  be  tracked  and  controlled,  to  apply  such 
controls,  to  keep  records  of  these  controls,  and  to  audit  that  these  controls  are  being  applied. 

3.9.3.2.1  Standards.  Table  3.9-10  presents  standards  for  software  configuration  management. 


TABLE  3.9-10  Software  configuration  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL- STD-4  91 

Adopted 

(Approved) 

NPC 

EIA 

National  Corucmui  Standard  for  Configuration 
Management 

IS-649 

Adopted 

(Approved) 

NPC 

ANSI/IEEE 

Software  Configuration  Management 

1042:1987 

Informational 

(Approved) 

NPC 

ANSI/IEEE 

Software  Configuration  Management  Plant 

828:1990 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Software  Documentation  Management 

FIPS  PUB 
105:1984 

Informational 

(Approved) 

GPC 

DOD 

Configuration  Management 

MIL-STD-973{I3): 

1995 

Informational 

(Approved) 

NPC 

EIA 

Trial  Utc  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Proceaaer  •  Software  Development  - 
Acquirer-Supplier  Agreement 

E1A/1EEE  JSTD- 
016:  1995 

Informational 

(Approved) 
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MIL-STD-498,  Software  Development  and  Documentation  has  been  approved  for  use  by  DOD 
with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each  Service. 

3.9.3.2.2  Alternative  specifications.  The  following  additional  guidance  document  is  also 
available:  Guidelines  for  Configuration  Management  (MIL-HDBK-761),  although  it  is  used  with 
MIL-STD-973(I3):  1995,  which  will  most  likely  be  canceled. 

3.9.3.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
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3.9.3.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.3.2.5  Related  standards.  None. 

3.9J.2.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  EIA/IEEE  J-STD-016: 1995  (formerly  IEEE  1498/ELA  IS  640)  is  based  on 
MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use  standard.  It  is 
anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as  an  ANSI 
standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of  ISO/1EC 
12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a  base 
standard  (12207 .OUS)  and  two  guides  (12207.1US  and  122.'  '"JS).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  piicr  M  July  1997.  The  gu’de  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 
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3.9J.3  Data  dictionary.  (This  BSA  appears  in  part  4  and  part  9.)  A  data  dictionary  is  a  part  of 
a  database  management  system  that  transparently  provides  a  centralized  meaning,  relationship  to 
other  data,  origin,  usage,  and  format  It  also  indicates  which  application  programs  use  that  data, 
so  that  when  a  change  in  a  data  structure  is  contemplated,  a  list  of  affected  programs  can  be 
generated.  The  data  dictionary  a  stand-alone  system  or  may  be  an  integral  part  of  the  DBMS  and 
used  to  control  it.  Data  integrity  and  accuracy  is  better  ensured  in  the  latter  case. 

3.93.3.1  Standards.  Table  3.9-1 1  presents  standards  for  data  dictionary. 


TABLE  3.9-11  Data  dictionary  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

NIST 

Information  Resource  Dictionary  System  (IRDS)  (adopts 
ANSI  X3.138-1988  and  X3.138A-199J) 

FIPS  PUB 
156:1989 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS) 
Framework 

10027:1990 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  45:1976 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  76:1980 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 

X3.138-1988 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface 

X3. 185*1992 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 
Export/Import  File  Formal 

X3. 195-1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface 

10728:1993 

Informational 

(Approved) 

CPC 

Metadata 

Coalition 

Metadata  Interchange  Specification  (MDIS) 

MDIS  1.0:1996 

Informational 

(Approved) 
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3.9.3.3.2  Alternative  specifications.  No  applicable  consortia  or  de  facto  specifications  for  the 
data  dictionary  are  available. 

3.9.3.3.3  Standards  deficiencies.  The  following  deficiencies  have  been  identified  in  the  available 
standards: 

a.  APIs  with  the  IRDS  are  not  currently  defined. 
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b.  There  are  no  IRDS  bindings  to  Ada. 

c.  IRDS  does  not  support  the  development  of  active  functionality. 

d.  IRDS  does  not  support  object-oriented  data  structures.  An  upcoming  major  IRDS 
revision  is  expected  to  add  support  for  object-oriented  data  structures  and 
communications  between  data  management  tools.  Computer  Aided  Software 
Engineering  (CASE)  tool  proponents  are  lobbying  for  this  revision. 

e.  IRDS  does  not  support  information  communications  among  data  management 
tools. 

f.  IRDS  conformance  tests  do  not  exist,  although  they  are  being  developed. 

g.  While  DOD  8320. 1  -M- 1  Data  Element  Standardization  Procedures,  January  1 993, 
provides  procedures  for  the  approval  and  maintenance  of  data  elements.  The 
standard  governing  the  design,  definition,  and  naming  rules  for  data  elements 
comes  from  Integration  Definition  for  Information  Modeling  (IBEF1X),  Corporate 
Information  Management  Process  Improvement  Methodology  for  DOD  Functional 
Managers  (1992).  This  has  been  adopted  as  FIPS  184. 

h.  There  are  no  implementations. 

3.9.3.3.4  Portability  caveats.  The  ANSI  and  ISO  services  interface  standards  have  diverged  and 
are  not  compatible.  All  attempts  to  converge  these  standards  have  failed  because  the  ANSI  and 
ISO  IRDS  specifiers  have  different  data  dictionary  interests.  As  a  result,  the  ISO  model  is  geared 
toward  developing  an  underlying  interface  between  the  dictionary  and  the  DBMS.  U.S.  Federal 
agencies,  the  NIST,  and  ANSI  focus  on  user  interfaces. 

One  example  of  how  ANSI  and  ISO  IRDS  diverge  is  concerned  with  whether  or  not  relationships 
are  permitted  to  have  attributes.  ISO  says  no,  on  the  grounds  that  its  simpler  model,  without 
attributes,  is  more  easily  integrated  with  SQL  tables.  ANSI  says  yes,  claiming  that  even  though  a 
model  permitting  attributes  is  more  complex  and  difficult  to  use,  it  provides  greater  flexibility  for 
more  IRDS  users.  People  using  IRDS  for  system  planning  processes,  for  example,  might  need  to 
store  certain  items  in  the  dictionary  that  would  not  necessarily  be  applicable  for  interfacing  with 
DBMSs. 

3.9.3.3.5  Related  standards.  The  following  standards  are  related  to  data  dictionaries  or  data 
dictionary  standards: 

a.  International  Telecommunications  Union  -  Telecommunications  Standards  Sector 
(ITU-T)  (formerly  International  Telegraph  and  Telephone  Consultative  Committee 
(CCITT))/ISO  X.500:  Directory  Services 
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b.  Standard  Textual  Language  (STL):  IEEE  1 175  (particularly  for  use  with  CASE 
tools) 

c.  Many  CASE  tools,  because  the  IRDS  acts  as  a  focus  for  sharing  data  and  metadata 
and  can  be  applied  to  them. 

d.  rnST  FIPS  183:  IDEFO 

e.  NIST  FIPS  184:  IDEF1X 

f.  Data  element  standards  in  the  data  dictionary  BSA,  above. 

3.9.3.3.6  Recommendations.  IRDS,  FIPS  156,  is  recommended.  Most  computer  vendors  claim 
that  they  are  committed  to  IRDS,  but  few  have  it  now.  If  specific  IRDS  documents  are  not 
specified  explicitly  in  a  procurement,  vendors  most  likely  will  propose  products  that  are  not 
compatible  with  IRDS. 

If  a  procurement  is  targeted  at  a  traditional  database  environment  and  a  simpler-to-use  IRDS  is 
desirable,  consider  the  ISO  specificadon.  If  other  environments  are  at  stake  and  attributes  on 
relationships,  or  many-to-many  relationships  are  needed  to  represent  the  relationships  between 
hardware  and  programs,  as  well  as  between  programs  and  data,  then  choose  FIPS  156  IRDS  and 
use  ANSI  IRDS  wherever  FIPS  156  has  not  specified  certain  capabilities.  Whether  the  choice  is 
for  ISO,  ANSI,  or  FIPS  IRDS,  be  prepared  to  lock  yourself  in  for  other  procurement,  rather  than 
mixing  ISO  and  ANSI  IRDS  because  of  the  incompatibilities. 
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3.9.3.4  Distributed  directory  services.  (This  BSA  appears  in  part  4,  part  9,  and  part  1 1.)  A 
directory  or  naming  service  provides  a  standardized  naming  scheme,  a  standardized  interface  with 
the  naming  facilities,  and  the  ability  for  the  interface  to  provide  transparent  access  to  a  variety  of 
naming  schemes  and  mechanisms  (e.g.,  DCE). 

Directory  service  applications  convert  a  name  into  a  physical  address  on  a  network,  providing 
logical  to  physical  conversion.  Names  can  be  user  names,  computers,  printers,  servers,  or  files. 
This  enables  users  to  find  these  resources  without  knowing  their  locations.  The  transmitting 
station  sends  a  name  to  the  server  containing  the  naming  service  software,  which  sends  back  the 
actual  address  of  the  user  or  resource. 

3. 9.3. 4.1  Standards.  Table  3.9-12  presents  standards  for  distributed  directory  services. 


TABLE  3.9-12  Distributed  directory  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

QSF 

HU 

DCE  1.1 
Directory:  1994 

Mandated 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Session  Service  Definition 

8326:1987 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnecdon-Connection-Oriented 
Session  Protocol 

8327:1987 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-  Bine  Connection  Oriented 
Presentation  Service  Definition 

8822:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Connection-Oriented 
Presentation  Protocol 

8823:1988 

Informational 

(Approved) 

IPC 

rru-T 

The  Directoiy:  Models  (X-ref:  ISO  9594-2) 

X.501  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Authentication  Framework  (X-ref:  ISO 
9594-8) 

X.509,  Version  3: 
1993 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directoiy:  Abstract  Service  Definition  (X-ref:  ISO 
9594-3) 

X.511  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
ref:  ISO  9594-4) 

X.518:  1993 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Protocol  Specification  (X-ref:  ISO  9594-5) 

X.519 (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directoiy:  Selected  Attributes  Types  (X-ref:  ISO 
9594-6) 

X.520  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Selected  Object  Classes  (X-ref:  ISO  9594- 
7) 

X.52I  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Replication  (X-ref:  ISO  9594-9) 

X.525 (1993) 

Informational 

(Approved) 

CPC 

X/Open 

Federated  Naming:  The  XFN  Specification 

C403  (7/95) 

Informational 

(Approved) 

NPC 

IEEE 

Directory  services/Name  space  API 

1224.2:1993 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Domnin  Name  Service  Profile  (Reference*  LAB  STD  13 
(RFC  1034, 1035)) 

MIL- STD-2045- 
17505:1994 

lafonnational 

(Affiwed) 

3.9.3.4.2  Alternative  specification.  There  are  no  alternative  specifications  available. 

3.9.3.4J  Standard  deficiencies.  Deficiencies  it.  .lie  existing  specifications  are  unknown. 

3.9.3.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.3.45  Related  standards.  There  are  no  related  standards. 

3.9.3.4.6  Recommendations.  OSF  DCE  directory  services  are  recommended  for  DCE 
applications.  For  more  information  on  non-DCE  directory  services,  see  the  Host  Application 
Support  BSA  in  part  7,  Communication  Services. 
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3.9.3.S  System  configuration.  (This  BSA  appears  both  in  part  8  and  part  9.)  System 
configuration  services  is  a  representation  of  the  components  and  component  parameters  of  a 
computer  system  (e.g.,  memory  boards,  amounts  of  memory,  memory  addresses,  particular 
interrupts,  networks,  network  addresses,  and  specific  peripherals  such  as  keyboards,  disk  drives, 
terminals,  mice  or  other  input  devices,  and  specialized  instruments).  Clearly,  every  computer 
must  have  a  way  to  do  this.  System  configuration  also  refers  to  the  automation  of  this  procedure 
(i.e.,  automated  system  configuration)  and  the  ability  to  configure  the  system  on-line.  On-line 
configuration  refers  to  the  ability  for  system  administrators  to  make  dynamic  configuration 
changes,  while  users  are  working  on-line,  rather  than  having  to  take  the  system  down. 

3. 9.3. 5.1  Standards.  Table  3.9-13  presents  standards  for  system  configuration. 


TABLE  3.9-13  System  configuration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNPoint  1  (Adopt*  ISO  Profile  Set*  11183-X,  12059- 
X,  end  12060- X,  include*  ISO/IEC  10164-X) 

OMNPoint  1:1993 

Adopted 

(Approved) 

PC 

ISO/IEC 

OSI  Syiteru  Management,  Put  1:  Object  Management 
Function 

10164-1:1993 

Informational 

(Approved) 

PC 

ISO/IEC 

OSI  Syitemi  Management,  Part  2:  State  Management 
Function 

10164-2:1993 

Informational 

(Approved) 

PC 

ISO/IEC 

OSI  Syttenu  Management,  Part  3:  Attribute*  for 

Re  pee  ten  ting  Relationship* 

10164-3:1993 

Informational 

(Approved) 

PC 

ISO/IEC 

OSI  System*  Management,  Part  12:  Test  Management 
Function 

10164-12:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

3.9.3.5.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.9.3.5.3  Standards  deficiencies.  The  present  ISO  10164-3,  "Attributes  for  Representing 
Relationships,"  and  10164-12,  "Test  Management  Function,"  standards  were  designed  with 
network  configuration  in  mind.  Theoretically,  these  standards  should  be  able  to  be  used  for 
configuration  management  of  any  computer  system.  Until  now,  very  little  work  has  been  done  in 
this  area,  either  in  standards  groups  or  in  products.  Exactly  how  these  standards  should  be  used 
in  host  management  is  undetermined. 

Versions  1.0  and  2.0  of  the  GNMP  specify  only  network  management  capabilities.  Not  until 
Version  3.0  is  available  will  the  GNMP  specify  the  management  information  required  for  general 
system  management,  such  as  host  computer  configuration  and  management,  operating  systems 
management,  and  database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CMIS/CMIP  for  the 
communication  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for  the 
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GNMP  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP  also.  One  reason  for 
this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  bindings  exist  for  the  configuration  management  standards  or  consortia  specifications. 

3.9 J.5.4  Portability  caveats.  Unknown 

3.9.3.5.5  Related  standards.  The  following  standards  r*e  related  to  system  configuration  or 
system  configuration  standards: 

a.  ISO/IEC  7498-4: 1989:  Management  Framework. 

b.  ISO/IEC  8571:1988:  File  Transfer,  Access,  and  Management  (FT AM),  as 
specified  in  GOSIP  Version  2  Sections  4.2.7.2  and  5.3. 1,  if  FTAM  functionality 
are  required. 

c.  ISO/IEC  8650:1988:  ACSE,  as  specified  in  GOSIP  Version  2,  Section  4.2.7. 1,  as 
modified  by  the  Network  Management  SIG  (NMSIG)  agreements  in  Part  18  of  the 
OSI  Implementors'  Workshop  (OIW)  Implementors  Agreements. 

d.  ISO/IEC  8824:1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.l). 

e.  ISO/IEC  8825: 1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1 . 

f.  ISO/IEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3. 1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  Remote  Operations  Service  Element  (ROSE),  as  specified  in 
the  Remote  Operations  Part  1 :  Model  Notation  and  Service  Definition  (ROSES), 
and  the  Remote  Operations  Part  2:  Protocol  Specification  (ROSEP),  and  as 
modified  by  the  NMSIG  agreements  clause  6.5. 

h.  ISO/IEC  9595:1991:  CMIS. 

i.  ISO/IEC  9596:1991:  CMIP. 

j.  ISO/IEC  10165-1:1993:  Structure  of  Management  Information  (SMI). 

k.  ISO/IEC  10165-2:1992:  Definition  of  Management  Information  (DMI). 

l.  ISO/IEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISO/IEC  DIS  1 1578.2:  Remote  Procedure  Call. 
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n.  IEEE  1224: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

o.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

p.  Comite  Consul tatif  International  de  Telegraphique  et  Telephonique  (CCITT) 
X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

s.  Internet  RFC  1157:  Simple  Network  Management  Protocol, 

t.  Internet  RFC  1213:  Management  Information  Base  for  Network  Managemeut  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  C315:5/94:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object 
Management). 

3.9.3.S.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 

To  build  or  procure  configuration  management  applications,  users  must  identify  the  system 
management  functions  that  are  applicable  to  their  requirements.  Then  they  must  identify  the 
various  ISO  10164  and  10165  standards  whose  specifications  are  related  to  these  requirements. 
Finally,  they  must  include  their  explicit  requirements  and  the  related  standards  in  the  RFP. 
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3.9.3.6  Network  configuration  management  Network  configuration  management  defines  the 
procedures  for  initializing,  operating,  and  closing  down  the  managed  objects,  and  the  procedures 
for  reconfiguring  the  managed  objects. 

3.9.3.6.1  Standards.  Table  3.9-14  presents  standards  for  network  configuration  management. 


TABLE  3.9-14  Network  configuration  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profife  Sea  1 1 183-X,  12059- 
X,  and  12060-X,  includes  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

OPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

5.9.3.6.2  Functionalities  supported.  This  network  service  supports  the  Network  Management 
functionality. 

3.9.3.6.3  Related  network  services.  Addressing  is  related  to  this  network  service. 

3.9.3.6.4  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.9.3.6.5  Recommendations.  The  OMNIPoint  program  defines  a  collection  of  specifications  for 
the  management  of  network  and  distributed  systems  using  open  standards  and  specifications.  It 
replaces  FIPS  179  (GNMP)  in  Version  3.0  of  the  NIST  Application  Portability  Profile. 

3.9.3.6.6  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 
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3.9.4  Usage  monitoring  and  cost  allocation.  Services  that  allow  monitoring  of  system  usage, 
allocation  of  resources,  and  assessment  of  charges  to  users. 

3.9.4.1  Software  license  management.  (This  BSA  appears  in  both  part  2  and  part  9.)  License 
management  addresses  the  problem  of  tracking  software  licenses  in  a  distributed  systems 
environment  The  DME  licensing  technology  includes  models  that  assist  users  in  keeping  track  of 
how  many  software  copies  are  needed  and  who  is  using  it  once  it  is  purchased.  Software  license 
management  for  a  system  provides  license  administration,  monitoring,  and  enforcement  services 
that  allow  more  detailed,  firm  and  equitable  licensing  terms  for  users,  and  better  protection 
against  illegal  software  usage  for  vendors. 

3.9.4.1.1  Standard.  Table  3.9-15  presents  standards  for  software  license  management 


TABLE  3.9-15  Software  license  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPC 

IEEE 

PQSEX  Syittm  Admnutr&fon  -  Put  2:  Software 
Adminiitretion  (former  P1003.7.2) 

1387.2:1995 

Adopted 

(Approved) 

CPC 

X/Open 

Syttemi  Management:  Attributed  Software  Adminiitration 
(XDSA) 

P429:1997 

Informational 

(Approved) 

„  _ 

1 

3.9.4.1.2  Alternative  specification.  The  following  specifications  are  also  available: 

a.  Hewlett-Packard:  Network  License  System  (NetLS)  Version  2.0  on  which  OSF's 
DME  License  Management  System  (LS)  is  based. 

b.  Gradient  Technologies:  PC  Client  libraries  for  license  management  and  PC  Ally 
server,  on  which  DME's  License  Management  PC  component  is  based. 

3.9.4.1.3  Standard  deficiencies.  No  Ada  bindings  exist  for  any  of  the  configuration  management 
standards  or  consortia  specifications. 

3.9.4.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.4.1.5  Related  standards.  The  following  standards  are  related  to  license  management  or 
license  management  standards: 

a.  1SO/IEC  JTC1  IS  9595:1991:  Common  Management  Information  Service 
(CMIS). 
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b.  ISO/IEC  JTC 1  IS  9596: 1 99 1 :  Common  Management  Information  Protocol 
(CM  IP). 

c.  ISO/IEC  IS  1 1578: 1996,  Information  Technology  -  Open  Systems 
Interconnection  -  Remote  Procedure  Call  (RPC). 

d.  Internet  RFC  1155  (STD  17):  Structure  and  Identification  of  Management 
Information  for  TCP/IP-based  Internets. 

e.  Internet  RFC  1 157  (STD  15):  A  Simple  Network  Management  Protocol. 

f.  Internet  RFC  1213  (STD  17):  Management  Information  Base  for  Network 
Management  of  TCP/IP-based  Internets  (MIB-II). 

g.  Network  Management  Forum:  OMNIPoint  1 . 

3.9.4.I.6  Recommendations.  IEEE  1387.2  is  recommended. 
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3.9.4.2  Accounting  management.  (This  BSA  appears  in  part  8  and  part  9.)  Accounting 
management  services  provide  the  ability  to  cost  services  for  charging  and  reimbursement  An 
effective  cost  management  system  should  contribute  to  the  development  of  a  sound  investment 
strategy  that  recognizes  and  evaluates  cost  and  alternatives.  The  services  should  also  provide  for 
the  ability  to  measure  and  prioritize  resource  usage  and  to  monitor  assets  and  maintain  costing 
records  for  chargeback  purposes.  Costs  of  information  technology  services  should  be  capable  of 
being  apportioned  to  users,  and  reports  of  those  costs  should  be  capable  of  being  provided  to 
management  and  customers. 

3.9.4.2.1  Standards.  Table  3.9-16  presents  standards  for  accounting  management. 


TABLE  3.9-16  Accounting  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

OSI  Syitemi  Management,  Pvt  lCh  Uuge  Metering 
Function  for  Accounting  PUrpote* 

10164-10:1995 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Syitom  Management,  Part  13:  Summarization 
Function 

10164-13:1995 

Adopted 

(Approved) 

GPC 

NIST 

Guideline  for  Developing  and  Implementing  a  Charging 
Sytfem  for  Data  Procuring  Service* 

FIPS  PUB  96:1982 

Adopted 

(Approved) 

3.9.4.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  OSF/1  O.S.:  Centralized  Accounting  Mgmt. 

b.  Berkeley  BSD  4.3  Unix. 

3.9.4.2.3  Standards  deficiencies.  A  variety  of  different  chargeback  systems  are  using  different 
metrics  and  methods  that  arc  causing  compatibility  problems  within  agencies  and  services.  The 
Unix  accounting  functions  are  designed  for  a  single  machine  environment 

The  present  ISO  10164-10,  "Accounting  Metering  Function,"  and  10164-13,  "Summarization 
Function,"  standards  were  designed  with  a  networked  system  configuration  in  mind.  Little  work 
has  been  done  in  standards  groups  or  products  to  determine  how  to  use  these  standards  for  host 
configuration  management. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  are  planned,  few  are  currently  available  or  sufficiently  complete.  For  example,  these 
library  specifications  have  incomplete  object  definitions  for  modems,  OS1  routers,  and  transport 
connections. 

The  ISO  standards  require  ISO  CMIS/CMIP  for  the  communication  of  management  information 
and  ISO  OSI  networking  protocols,  and  do  not  interoperate  with  TCP/IP. 

No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 
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3.9.4.2.4  Portability  caveats.  OSF/1  uses  the  System  V  Unix  accounting  facilities.  Although  the 
OSF/1  and  System  V  accounting  systems  differ,  and  each  operating  system  has  extra  accounting 
functions,  the  use  of  the  same  accounting  facilities  eliminates  one  source  of  incompatibility. 

3.9.4.2.5  Related  standards.  The  following  standards  are  related  to  accounting  management  or 
accounting  management  standards: 

a.  ISO/IEC  7498:1986:  Management  Framework. 

b.  ISO/IEC  8571:1988:  FTAM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7. 2 
and  5.3.1,  if  FTAM  functionality  art  required. 

c.  ISO/IEC  8650:1988:  ACSE,  as  specified  in  OOSIP  Version  2,  Section  4.2.7. 1,  as 
modified  by  the  NMS1G  agreements  in  Part  18  of  the  OIW  Implementors 
Agreements. 

d.  ISO/IEC  8824:  W*"’:  c oeclfiention  of  Abstract  Syntax  Notation  1  (ASN.l). 

e.  ISO/IEC  8825:1  '.v  Ipecui, Encoding  Rules  for  ASN.l. 

f.  ISO/IEC  9041:1990  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3.1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  ROSE,  as  specified  in  the  Remote  Operations  Part  1 :  Model 
Notation  and  Service  Definition  (ROSES),  and  the  Remote  Operations  Part  2: 
Protocol  Specification  (ROSEP),  and  as  modified  by  the  NMS1G  agreements 
clause  6.5. 

h.  ISO/IEC  9595:1991  CMIS. 

i.  ISO/IEC  9596:1991  CMIP. 

j.  ISO/IEC  10165-1:1993:  SMI. 

k.  ISO/IEC  10165-2:1992:  DMI. 

l.  ISO/IEC  10 165-4: 1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISO/IEC  DIS  11578.2:  RPC. 

n.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 
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o.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 

anguage  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  S  (Upper  Layer 
Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
Internets  based  on  TCP/IP. 

s.  Internet  RFC  1 157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1213:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  Network  Management  Forum:  OMNIPoint  1. 

v.  X/Open:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object  Management). 

3.9.4.2.6  Recommendations.  To  build  or  procure  account  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  within  the  ISO  10164  and  101o5  standards  that  are  related 
to  these  requirements.  Finally,  they  must  explicitly  include  the  requirements  and  the  related 
standards  in  the  RFP. 

In  the  future,  the  NIST  plans  to  provide  a  capability  in  the  GNMP  to  integrate  the  present  GNMP 
with  SNMP. 
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3.9.4.3  System  resource  limits.  (This  BSA  appears  both  in  part  8  and  part  9.)  Resource  limits 
functionality  allow:  system  administrators  to  control  the  amount  of  system  resources  available  to 
users. 


3.9.4.3.I  Standards.  Table  3.9-17  presents  standards  for  system  resource  limits. 


TABLE  3.9-17  System  resource  limits  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pijjH 

CC 

XJOpec 

Single  Unix  Specification  (Spec.  1 170).  Syatem  Interface* 
and  Header*,  Iuue  4.  Venkn  2.  (Part  of  XPG4) 

C435  (9/M) 

Adopted 

(Approved) 

NPC 

IEEE 

1003.10:1995 

InfomutionaJ 

(Approved) 

' 

Hsfi 

Bum 

SmBI 

IfcSEl 

3.9.4J.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Berkeley  4.3  Unix. 

b.  Cray  Research,  Inc.:  "limits"  interfaces. 

c.  OSF:  OSF/1  Operating  System:  "getrUmit/setrlimit" 

3.9.4.3 J  Standards  deficiencies.  The  Berkeley  Unix  and  System  V  "setrlimit"  and  "ulimit" 
interfaces  have  the  limitation  that  users  may  act  only  to  make  their  limits  more  restrictive. 

3.9.4.3.4  Portability  caveats.  The  actual  numeric  limit  values  for  different  resource  limits  are  not 
portable  across  various  platforms.  Applications  need  to  provide  some  sort  of  configuration 
parameters  to  specify  the  actual  numeric  values  for  each  site. 

3.9.4.35  Related  standards.  The  following  standards  are  related  to  resource  limits  or  resource 
limit  standards: 


a.  ISO/IEC  9945- 1 : 1 996:  POSIX.  1  System  Application  Programming  Interfaces. 

b.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  PI 387.1:  POSIX  System  Administration  -  Part  1 :  Overview. 

d.  IEEE  1003.2d:19S4:  POSIX  Batch  Environment  Amendments. 

3.9,4.3.6  Recommendations.  X/Open  Single  Unix  Specification  (SUS)  provides 
"setrlimit/getrlimit"  functionality. 
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3.9.5  Performance  monitoring.  Performance  monitoring  services  allow  information  technology 
resources  to  be  managed  efficiently.  Performance  aspects  of  hardware,  software,  and  network 
components  must  be  monitored  and  subsequently  made  available  to  the  system  manager.  The 
manager  must  then  have  access  to  services  and  parameters  with  which  to  tune  the  system  to  meet 
performance  targets. 

3.9.5.1  Software  management  indicators.  (This  BSA  appears  both  in  part  2  and  part  9.) 
Software  management  indicators  aid  in  managing  the  software  development  process.  Various 
measurements  of  both  software  products  and  software  processes  are  available.  Product 
measures(such  as  tines  of  code,  function  points,  etc.)  are  often  associated  with  the  product 
specification  and  should  be  used  as  management  indicators  throughout  the  product  life  cycle. 
Process  measures(such  as  software  trouble  reports)  should  be  tracked  to  determine  whether  the 
software  development  process  is  within  statistical  control  limits.  Key  indicators  should  be 
identified  in  the  software  development  plan,  and  the  developer  should  then  collect,  analyze, 
interpret,  take  corrective  actions,  and  report  on  the  selected  key  management  indicators. 

3.9.5.1.1  Standards.  Table  3.9-18  presents  standards  for  software  management  indicators. 


TABLE  3.9-18  Software  management  indicators  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

d-od 

Software  Development  and  Documentation 

MIL-STD-498 

Adopted 

(Approved) 

[PC 

ISO/ffiC 

Quality  Characteristics  and  Guidelines  for  Their  Use 

9126:1991 

Adopted 

(A^iroved) 

NPC 

fFFF. 

Use  of  Standard  Measures  to  Produce  Reliable  Software 

982.2:1988 

Informational 

(Approved) 

NPC 

IEEE 

Standard  Dictionary  of  Measures  to  Produce  Reliable 
Software 

982.1:1988 

Infoimational 

(Approved) 

NPC 

IEEE 

Software  Productivity  Metrics 

1045:1992 

Informational 

(Approved) 

NPC 

1FRF 

Software  Quality  Metrics  Methodology 

1061:1992 

Informational 

(Approved) 

tPC 

ISO/IEC 

Software  Life  Cycle  Processes 

12207:1995 

Informational 

(Approved) 

NPC 

E1A 

Trial  Use  Standard  -  Standard  for  Information  Technology 
•  Software  Life-Cycle  Processes  -  Software  Development  • 
Acquirer- Supplier  Agreement 

Informations! 

(Approved) 
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MIL-STD-498,  Software  Development  and  Documentation  has  been  approved  for  use  by  DOD 
with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each  Service. 

3.9.S.I.2  Alternative  specifications.  For  additional  metrics  information,  consult  the  following 
documents: 

a.  Metrics  for  I-CASE  Pilot  Project  (MIPP)  Program,  Metrics  Reporting  Guidebook, 
(prepared  by  Mitre  Corporation,  27  May  1994,  for  DISA/JIEO/CIM/TXEM). 

b.  Practical  Software  Measurement:  A  Guide  to  Objective  Program  Insight,  Draft  12 
April  1995. 

c.  Streamlined  Integrated  Software  Metrics  Approach  (SISMA)  Guidebook; 
Application  of  STEP  Metrics,  (prepared  by  Software  Productivity  Solutions, 
Indialantic,  FL  32903, 12  July  1993,  for  the  U.S.  Army). 

d.  Software  Measurement  Guidebook,  (prepared  by  the  Software  Productivity 
Consortium  Services  Corporation,  December  1992,  Herndon  VA,  for  DARPA). 

3.9.5.1J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.5.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.5.1.5  Related  standards.  Related  software  management  guidance  can  be  found  in  the 
Software  Engineering  Institute's  Capability  Maturity  Model  (CMM).  The  Software  Engineering 
Institute's  CMM  provides  guidance  on  how  to  gain  control  of  the  software  development  and 
maintenance  processes.  The  CMM  has  defined  an  evaluation  procedure,  the  CMM  Based 
Appraisal  (CBA),  as  a  means  of  identifying  the  risks  associated  with  potential  contractor 
performance.  Diagnostic  tools  based  on  the  CMM  have  been  deployed.  One  of  those  tools,  the 
Software  Capability  Evaluation(SCE),  is  designed  to  be  used  by  an  acquiring  organization  to 
either  identify  process  risks  associated  with  a  particular  proposal  during  the  source  selection  or  to 
monitor  the  risk-reducing  process  improvements  during  the  contract  execution. 

3.9.5.1.6  Recommendations.  The  adopted  standards  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  MIL-STD-498  contains  requirements  for  security  and  privacy  for  software 
development  and  documentation.  ElA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/EIA  IS  640) 
is  based  on  MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  ElA/IEEE  trial  use 
standard.  It  is  anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as 
an  ANSI  standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of 
1SO/IEC  12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a 
base  standard  (12207 .0US)  and  two  guides  (12207.1US  and  12207. 2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
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12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  policy,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

For  other  related  information,  consult  ISO/IEC  9126.  Appropriate  standards  should  be  selected 
based  on  software  metrics  requirements. 
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3.9J.2  Performance  management.  (This  BSA  appears  in  part  8  and  part  9.)  Performance 
management  provides  services  and  interfaces  for  tuning  systems  and  subnetworks  to  meet 
individual  performance  requirements.  Performance  management  enables  the  behavior  of 
resources  and  the  effectiveness  of  communication  activities  to  be  evaluated.  It  includes  functions 
to:  gather  statistical  information;  maintain  and  examine  logs  of  system  state  histories;  determine 
system  performance  under  natural  and  artificial  conditions;  and  alter  system  modes  of  operation 
for  the  purpose  of  conducting  performance  management  activities.  Performance  management 
may  make  use  of  event  management  facilities. 

3.9.5. 2.1  Standards.  Table  3.9-19  presents  standards  for  performance  management 


TABLE  3.9-19  Performance  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ii^n 

GPC 

NIST 

FIPS  PUB 
144:1985 

Adopted 

(Approved) 

CPC 

N'MF 

OMNIPoint  I  (Adopti  ISO  Profile  Set*  1 1 183-X,  12059- 
X,  end  12060-X,  includes  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OS  I  Syitemi  Management,  Part  1 1 :  Metric  Object!  and 
Attribute* 

10164-11:1994 

Informational 

(Approved) 

GPC 

NIST 

Guideline  on  Computer  Performance  Management:  An 
Introduction 

FIPS  PUB  49:1977 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  for  the  Me«*ureme«it  of  Interactive  Computer 
Service  Retpome  Time  and  Turnaround  Time 

FIPS  PUB  57:1978 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

myu 

Informational 

(Approved) 

GPC 

NiST 

Guideline*  'or  Meaturement  of  Remote  Batch  Computer 
Service 

FIPS  PUB  72:1980 

Informational 

(Approved) 

3.9.5.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.9.5.2.3  Standards  deficiencies.  The  present  10164- 1 1  ("Workload  Monitoring  Function)  and 
generic  10165-xx  standards  were  designed  with  network  configuration  in  mind.  Theoretically, 
they  should  be  able  to  be  used  for  configuration  management  of  any  computer  system.  Little 
work  has  been  done  in  this  area,  either  in  standards  groups  or  in  products.  Exactly  how  these 
standards  should  be  used  in  host  management  is  undetermined.  Standards  for  system  performance 
measurement  are  needed. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  and  support  performance  management  of  network  resources  are  planned,  few  are 
currently  available  or  sufficiently  complete.  For  example,  these  library  specifications  have 
incomplete  object  definitions  for  modems,  OS  I  routers,  and  transport  connections.  Based  on 
needs  of  the  U.S.  Federal  Government  (as  shown  by  NIST  surveys),  the  GNMP  added  more 
object  class  specifications  and  definitions.  These  include  the  following  objects:  LANs,  X.25 
WANs,  ISDN,  FDD1,  modems,  bridges,  links,  and  a  rudimentary  capability  to  manage  OS1 
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routers  and  transport  connections.  Phase  2  GNMP  objects  also  will  include  protocol  software 
flayers  3-7),  routers,  terminal  servers,  MTAs,  PBXs,  and  circuit  switches. 

Versions  1.0  and  2.0  of  the  GNMP  currently  specify  only  network  management  capabilities.  Not 
until  Version  3.0  will  the  GNMP  specify  the  management  information  required  for  general  system 
management,  such  as  host  computer  configuration  and  management,  operating  systems,  and 
database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CMIS/CMIP  for  the 
communication  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for  the 
GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP.  One 
reason  for  this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  binding  is  available  for  the  ISO  system  management  standards. 

Performance  management  could  make  use  of  generalized  event  management  facilities,  but  most 
products  currently  implement  their  own  event  management 

3.9.5.2.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.5.2.5  Related  standards.  The  following  standards  are  related  to  performance  management  or 
performance  management  standards: 

a.  ISO/IEC  7498-4: 1989:  Management  Framework. 

b.  ISO/DEC  8571:1988:  FT  AM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7. 2 
and  5.3.1,  if  FTAM  functionality  are  required. 

c.  ISOAEC  8650:1988:  Association  Control  Service  Element  (ACSE),  as  specified  in 
GOSIP  Version  2,  Section  4,2.7. 1,  as  modified  by  the  NM5IG  agreements  in  Part 
18  of  the  OIW  Implementors  Agreements. 

d.  ISOAEC  8824:1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.  1). 

e.  ISOAEC  8825: 1990:  Specification  of  Basic  Encoding  Rules  for  ASN.  1 . 

f.  ISOAEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  A.2.12  and  5.3.1,  if  virtual  terminal  functionality  is  required. 

g.  ISOAEC  9072:1989:  ROSE,  as  specified  in  the  Remote  Operations  Part  1 :  Model 
Notation  and  Service  Definition  (ROSES),  and  the  Remote  Operations  Part  2: 
Protocol  Specification  (ROSEP),  and  as  modified  by  the  NMSIG  agreements 
clause  6.5. 
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h.  ISO/IEC  9595:1991:  CMIS. 

L  ISO/IEC  9596: 1991:  CMIP. 

j.  ISO/IEC  10165-1:1993:  SMI. 

k.  ISO/IEC  10165-2:1992:  DMI. 

L  ISO/IEC  10165-4:1992:  GDMO. 

m.  ISO/IEC  DIS  11578.2:  RPC. 

n.  CC1TT  X.400  Message  Handling  System  (MHS),  as  specified  in  COSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

o.  IEEE  1224: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7,  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

s.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1 158;  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  C315:5/94:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object 
Management). 

3.9.5.2.6  Recommendations.  To  procure  performance  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  in  the  ISO  10164  and  10165  standards  related  to  these 
requirements.  Finally,  they  must  include  their  requirements  and  the  related  standards  in  the  RFP. 

The  OMNIPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
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Version  3.0  of  the  NIST  Application  Portability  Profile.  OMNIPoint  adopts  the  ISO  10164  and 
10165  series  of  standards. 

FIPS  144  is  a  mandatory  standard  according  to  the  Federal  ADP  and  Telecommunications 
Standards  Index  and  shall  be  used  if  it  satisfies  the  user's  requirements. 
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3.9.5 .3  Network  flow  control.  Flow  control  refers  to  the  regulation  of  the  movement  of 
datagrams  through  the  transfer  process.  It  includes  the  ability  to  manage  the  size  of  the 
information  at  various  stages  in  the  process. 

3.9.5.3.1  Standards.  Table  3.9-20  presents  standards  for  network  flow  control. 


TABLE  3.9-20  Network  flow  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Transmission  Control  Protocol 

Standard  7/RFC- 
793 

Mandated 

(Approved) 

tPC 

IAB 

Host  Requirement* 

Standard  3/RFC- 
I122/RFC-U23 

Mandated 

(Approved) 

IPC 

IAB 

The  Point-to-point  Protocol  (PPP) 

Standard  51/RFC 
1661 

Mandated 

(Approved) 

GPC 

DOD 

Tram  port  Profile:  Reliable  End  System  Transport  for  DOD 
Communications 

MtL-STD-2045- 
14500  Part 

1:  March  1994 

Information*] 

(Approved) 

GPC 

DOD 

Internet  Transport  Profile  for  DOD  Communications  Wide 
Area  Network  Access  (References  ISO  8208  Information 
Processing  Systems  -  Data  communications  •  X.25  Packet 
Level  Protocol  for  Data  Terminal  Equipment) 

MIL-STD-2C45- 
14502  Part  3  July 
1994 

Informational 

(Approved) 

GPC 

DOD 

Transport  Profile:  Balanced  Point-to-Point  Digital  Data 
Circuit 

MIL-STD-2045- 
14500  Put 

2:  March  1994 

Informational 

(Approved) 

GPC 

DOD 

Transport  Profile:  Subnetwork  for  an  Unbalanced  Date 
Link 

MIL-STD-2045- 
14500  Part 
3:March  1994 

Informational 

(Approved) 

GPC 

DOD 

Internet  Transport  Profile  for  DOD  Communications: 
Point-to-Point  Links 

MILSTD-2045- 
14502  Part  2  July 
1994 

Informational 

(Approved) 

<K 

“-'V  v 

OCIO 

tarn 

3.9.5.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.9.5.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.9.5.3.4  Portability  caveats.  Connection-oriented  transport  classes  do  not  interoperate. 
Applications  using  different  classes  of  transport  service  will  have  portability  problems.  Class  Zero 
connection-oriented  transport  must  be  provided  along  with  X.25  if  public  messaging  systems  are 
to  be  connected  to  the  procured  systems. 

The  X.25  equipment  that  conforms  to  different  X.25  specification  dates  (e.g.,  1980,  1984,  1988, 
1992)  can  have  interoperability  problems. 

3.9.5.3.5  Related  standards.  There  are  no  related  standards. 
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3.9iJ.(  Recommendations.  Flow  control  is  one  of  the  functions  supported  by  the  Transmission 
Control  Protocol  (TCP).  The  TCP  should  be  used  as  specified  in  the  IAB  STD  7.  The  LAB  STD 
3  identifies  and  corrects  errors  in  the  TCP. 

MIL-STD-2045- 14500-01  should  be  used  for  legacy  systems  interoperability.  It  uses  Class  Four 
connection-oriented  transport  protocol  is  one  of  the  base  standards.  It  provides  the  most  reliable 
transport  service  and,  in  turn,  assumes  the  least  about  the  network  layer  services  supporting 
transport  Implementations  requiring  use  of  TP4  for  flow  control  services  should  comply  with 
MIL-STD-2045- 14500-01.  A  connection-oriented  transport  class  must  be  chosen  based  on  the 
reliability  of  the  other  OSI  layers  in  the  system.  MIL-STD-2045- 14500  parts  2  and  3  should  be 
used  for  legacy  systems.  For  legacy  systems,  LAPB  should  be  used  as  specified  in  MIL-STD- 
2045-14500  Parts  2  and  3. 

If  recommended  standards  do  not  meet  system  requirements,  or  are  cost  prohibitive,  standards  for 
the  legacy  systems  may  be  used  as  long  as  interoperability  is  not  impacted.  The  use  of  legacy 
systems  standards  may  require  a  waiver  from  the  appropriate  authority.  MIL-STD-2045-44000  is 
an  emerging  standard.  It  uses  TCP  and  UDP  with  enhancements  to  meet  specific  requirements 
for  high-stress  resource  constrained  environments, 
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3.9.S.4  Network  sequencing.  Sequencing  is  a  function  performed  by  the  N-layer  to  preserve  the 
order  of  N-service  data  units  that  were  submitted  to  the  N-layer  (ISO  7498). 

3. 9.5. 4.1  Standards.  Table  3.9-21  presents  standards  for  network  sequencing. 


TABLE  3.9-21  Network  sequencing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

pmn 

IPC 

IAB 

Tnmmiiikm  Control  Protocol 

Standard  7/RPC  - 
793 

Mandated 

(A|*>roved) 

IPC 

LAB 

Host  Requirement! 

Standard  3/RFC- 
1122/RFC-l  123 

Mandated 

(Approved) 

IPC 

IAB 

The  Point-to-Point  Protocol  (PPP) 

Standard  51/RFC 
1661 

Mandated 

(Approved) 

GPC 

DOD 

Internet  Transport  Profile  few  DOD  Communication!  Wide 
Are*  Network  Acce*i  (Reference!  ISO  8206  Information 
Pro  ceiling  Syitemi  -  Data  communication!  •  X.25  Packet 
Level  Protocol  for  Data  Terminal  Equipment) 

MIL-STD-2045- 
14502  Part  3  July 
1994 

Informational 

(Approved) 

GPC 

DOD 

Internet  Trim  port  Profile  for  DOD  Communication!: 
Point-to-Point  Link! 

MIL-STD-2045- 
14502  Part  2  July 
1994 

Informational 

(Approved) 

GPC 

DOD 

Traniport  Profile:  Reliable  End  Syitem  Tramport  for  DOD 
Communication! 

MIL-STD-2045- 
14500  Part 
l:March  1994 

Informational 

(Approved) 

GPC 

DOD 

Traniport  Profile:  Balanced  Point-to-Point  Digital  Data 
Circuit 

imrKTxm. 

nnoi 

Informational 

(Approved) 

GPC 

DOD 

Traniport  Profile:  Subnctwoik  for  an  Unbalanced  Data 
Link 

Informational 

(Approved) 

OK 

WtiSM 

BfilSis 

Mil 

1 

3.9.5.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.9.5.4.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.9.5.4.4  Portability  caveats.  Connection-oriented  transport  has  five  levels  of  service  that  deal 
with  reliability.  These  classes  do  not  interoperate.  Applications  using  different  classes  of 
transport  service  will  have  portability  problems.  Class  Zero  connection-oriented  transport  must 
be  provided  along  with  X.25  if  public  messaging  systems  are  to  be  connected  to  the  procured 
systems. 

The  X.25  equipment  conforming  to  different  specification  dates  (e.g.,  1980,  1984,  1988,  1992) 
can  have  interoperabilty  problems. 

3.9.5.4.5  Related  standards.  There  are  no  related  standards. 
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3.9.S.4.6  Recommendations.  Sequencing  is  one  of  the  functions  supported  by  Transmission 
Control  Protocol  (TCP).  The  TCP  should  be  used  as  specified  in  the  IAB  STO  7.  The  LAB  STD 
3  identifies  and  corrects  errors  in  the  TCP. 

MIL-STD-2045-14500-01  is  recommended  for  legacy  systems  interoperability.  ItusesTP4as 
one  of  its  base  standards.  The  Class  Four  transport  provides  the  most  reliable  transport  service. 

It  assumes  that  the  underlying  network  service  is  unreliable.  A  connecdon-c.iented  transport 
class  must  be  chosen  based  on  the  reliability  of  the  other  OSI  layers  in  the  system.  MIL-STD- 
2045-14500  parts  2  and  3  are  recommended  for  legacy  systems  use.  LAPB  should  be  used  as 
specified  in  MIL-STD-2045-14500  Parts  2  and  3. 

If  recommended  standards  do  not  meet  system  requirements,  or  are  cost  prohibitive,  standards 
from  the  legacy  column  may  be  used  as  long  as  interoperability  is  not  impacted.  The  use  of  legacy 
systems  standards  may  require  a  waiver  from  the  appropriate  authority.  MIL-STD- 2045-44000  is 
an  emerging  standard.  It  uses  TCP  and  UDP  with  enhancements  to  meet  specific  requirements 
for  high-stress  resource  constrained  environments. 
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3.9.53  Communication  of  management  information.  (This  BSA  appears  in  part  8  and  part  9.) 
Communication  of  management  information  refers  to  a  mechanism  and  protocol  with  extensions 
specifically  geared  to  the  communication  of  data  and  information  used  by  system  management  and 
network  management  applicadons  for  monitoring  and  controlling  resources.  This  management 
information  may  be  shared  between  management  processes  and  structured  according  to  the 
requirements  of  those  processes. 

3.93.5.1  Standards.  Table  3.9-22  presents  standards  for  communication  of  management 
information. 


TABLE  3.9-22  Communication  of  management  information  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Simple  Network  Management  Protocol  (SNMP) 

Standard  I5/RPC- 
1157 

Mandated 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profile*  -  Internet  Network  Management 
Profile  for  DoD  Communication* 

MIL-STD-2045- 

17507:7/94 

Informational 

(Approved) 

CPC 

NMF 

OMNlPoinl  1  (Adopt*  ISO  Profile  Set*  1 1 183-X,  12059* 

X.  and  12060-X,  include*  ISO/IEC  10164*X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Service*  (CMIS) 
Definition,  with  Amendment  4:  Acce**  Control 

9595:1991/ 

AM4M992 

Informational 

(Approved) 

IPC 

1SO/IEC 

Information  Technology  -  Open  Sytlem*  Interconnection  • 
Common  Management  Infomtation  Protocol  (CMIP)  -  Part 

I:  Specification  (Include*  amendment  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Element*  of  Management  Information  Relating  to  OSI 
Network  Layer  Standard* 

10733:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

10742:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 

CPC 

X/Open 

Management  Protocol  Profile*  (XMPP) 

C206  (11/93) 

Informational 

(Approved) 

CPC 

IETF 

Protocol  Operation*  for  Simple  Network  Management 
Protocol,  venion  2  (SNMPv2) 

RFC  1448:1993 

Informational 

(Approved) 
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3.9.5.5.2  Alternative  specifications.  Hewlett-Packard's  Postmaster,  on  which  the  OSF  DME's 
CM1P  and  Simple  Network  Management  Protocol  (SNMP)  implementations  are  based,  is  also 
available. 

3.9.5.5.3  Standards  deficiencies.  With  its  object-oriented  approach,  CMIS/CMIP  has  a  relatively 
expensive  initial  application  implementation  cost.  This  flaw  is  offset  by  a  low  maintenance  cost, 
because  CMIS/CMIP  allows  objects  to  be  added,  and  an  associated  level  of  management  to  be 
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provided,  at  a  small  incremental  cost  There  is  no  standard  API  to  CMIS/CMIP.  Only  a  limited 
number  of  narrowly  focused  applications  are  implemented  with  it  It  lacks  a  complete  set  of 
associated  object  definitions  needed  for  network  management  and  sufficient  associated  security 
standards. 

The  SNMP  is  a  simple  request-and-reply  protocol.  It  performs  all  its  operations  using  a  fetch- 
and-store  paradigm,  rather  than  defining  a  large  set  of  commands.  Effectively,  the  SNMP 
network  manager  is  restricted  to  only  two  commands  that  are  performed  on  Management 
Information  Base  (MIB)  data  items:  "set"  and  "get."  Variables  are  retrieved  (get)  or  modified 
(set).  All  other  operations  are  defined  as  side-effects  of  the  "set"  operation. 

The  SNMP's  chief  disadvantage  is  the  fact  that  its  simplicity  severely  limits  the  protocol's  ability  to 
satisfy  users'  requirements  for  event  reporting,  sufficient  control,  and  extensibility.  Because 
SNMP  is  so  simplistic  and  limited,  it  provides  more  of  a  monitoring  and  data  gathering  capability 
than  a  management  function. 

The  SNMP  accommodates  only  limited  event  reporting  by  means  of  the  "trap"  mechanism.  Other 
events  must  be  discovered  by  the  managing  node  by  means  of  periodic  polling.  Its  simplicity 
compromises  its  ability  to  support  consistent  or .  atenrive  addressing.  It  has  limited  security 
capabilities,  and  does  not  support  threshold-driven  performance  notification  except  indirectly 
through  side  effects  or  "set"  operations  on  MIB  items.  SNMP  cannot  be  extended  easily. 

The  SNMP  has  a  high  maintenance  cost  Although  the  first  implementation  of  SNMP  is  relatively 
inexpensive,  SNMP's  simplicity  so  severely  limits  its  extensibility  that  future  SNMP  developments 
are  more  likely  to  occur  in  the  form  of  new  proprietary  and  standard  Management  Information 
Bases  (MIBs)  rather  than  as  SNMP  enhancements.  Each  additional  MIB  will  require  changes  and 
additions  to  its  existing  specific  applications  to  support  new  functions.  New  MIBs  also  will 
require  a  unique  application  code  to  be  developed,  modified,  documented,  and  supported.  MIB 
development  and  maintenance  can  result  in  a  high  cost  to  users  and  vendors  and  present  a  major 
SNMP  concern. 

The  SNMP  lacks  an  object-oriented  approach  to  network  management.  The  lack  of  object 
orientation  is  a  major  factor  limiting  the  SNMP's  extensibility  and  its  ability  to  support  legacy 
systems,  support  system  and  network  management,  and  make  complex  distributed  system 
management  more  intuitive. 

It  lacks  the  ability  to  manage  a  network  of  networks  in  which  different  managers  must  interact  on 
a  peer-to-peer  basis. 

Because  the  SNMP  cannot  be  extended  easily,  and  extensions  require  changes  to  SNMP 
applications,  developing  new  SMP  products  rather  than  retoobng  existing  ones  probably  will  be 
less  costly. 
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The  future  of  SMP  is  uncertain  because  it  is  unclear  whether  vendors  will  want  to  develop  new 
products  for  a  protocol  that  is  incompatible  with  the  major  systems  management  standards  today 
(e.g.,  from  ISO.  NMF,  X/Open,  and  OSF).  SMP  is  still  less  functional  than  CMIS/CMIP. 

The  SMP  is  not  an  Internet  standard.  Although  developed  in  response  to  a  request  issued  by  the 
Internet  Engineering  Task  Force  (IETF)  for  art  improved  SNMP,  SMP  was  developed  outside  the 
IETF.  Furthermore,  the  SMP  developers  do  not  plan  to  submit  it  as  a  proposed  Internet  standard. 
They  feel  that  submitting  SMP  to  a  committee  would  subject  it  to  alteration  and  a  lengthy  review, 
and  would  slow  down  development  of  a  coherent  technology. 

SMP  is  not  accepted  by  groups  such  as  the  Network  Management  Forum  (NMF),  X/Open,  OSF, 
and  the  National  Institute  of  Standards  and  Technology  (NIST).  These  groups  are  resistant  to 
SMP  because  it  lacks  an  object-oriented  approach  to  network  management.  Despite  the 
improvements,  without  object  orientation,  SMP  is  still  incompatible  with  the  ISO  and  NMF 
network  managemr  u  model,  as  well  as  with  the  OSFs  Distributed  Management  Environment 
(DME)  and  X/Open's  systems  management  specifications.  Vendors  moving  from  SNMP  to  SMP 
may  find  it  more  cost  effective  to  develop  new  SMP  products. 

SMP  is  not  easily  extensible,  and  like  SNMP,  is  expensive  to  extend.  This  is  largely  due  to  SMP's 
lack  of  an  object-oriented  approach  to  network  management 

3.9.5.5.4  Portability  caveats.  Nonstandard  SNMP  MIB  definitions  have  proliferated. 

The  SNMP  MIB  is  tailored  to  accommodate  only  Internet  equipment.  Despite  the  X/Open,  OSF, 
and  former  UI  (now  X/Open)  consolidated  interface  to  CMIP  and  SNMP  (X/Open  Management 
Protocol  (XMP)  and  CM-API),  without  object-orientation  SNMP  is  still  incompatible  with  the 
ISO  and  NMF  network  management  model,  as  well  as  with  the  OSFs  Distributed  Management 
Environment  (DME)  and  X/Open's  systems  management  specifications. 

SNMP's  design  does  not  lend  itself  to  migration  from  and  coexistence  with  legacy  systems.  For 
example,  SNMP  does  not  support  the  ability  to  send  the  same  operation  to  different  classes  of 
objects  (an  important  concept  known  in  this  context  as  "polymorphism,"  which  CMIS/CMIP 
supports). 

3.9.5.5.5  Related  standards.  The  following  standards  are  related  to  management  information 
communication  standards: 

a.  ISO/IEC  7498:1986:  Management  Framework. 

b.  ISO/IEC  8326: 1 987  and  8327 : 1 987 :  Connection-Oriented  Session  Service  and 
Connection-Oriented  Session  Protocol,  respectively. 

c.  ISO/IEC  8326  AD  2:  Connection-Oriented  Session  Service  -  Incorporation  of 
Unlimited  User  Data. 
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d.  ISO/IEC  8327  AO  2:  Connection -Oriented  Session  Protocol  -  Incorporation  of 
Unlimited  User  Data. 

e.  ISO/IEC  8571:1988:  FTAM,  as  specified  in  GOSIP  Version  2  Sections  4.2.7.2 
and  5.3.1,  if  File  transfer,  Access,  and  Management  functionality  are  required. 

f.  ISO/IEC  8649: 1988  and  8650: 1988:  Association  Control  Service  Element  (ACSE) 
and  Association  Control  Protocol  (ACP),  as  specified  in  GOSIP  Version  2, 

Section  4.2.7. 1,  as  modified  by  the  NMSIG  agreements  in  Part  18  of  the  OIW 
Implementors  Agreements. 

g.  ISO/IEC  8822:1988  and  8823:1988:  Connection-Oriented  Presentation  Service 
and  Connection-Oriented  Presentation  Protocol,  respectively. 

h.  ISO/IEC  8824:1990:  Abstract  Syntax  Notation  1  (ASN.l). 

L  ISO/IEC  8825: 1 990:  Basic  Encoding  Rules  (BER)  for  ASN.  1 . 

j.  ISOAEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3. 1,  if  virtual  terminal  functionality  is  required. 

k.  ISOAEC  9072- 1 : 1989  and  9072-2: 1 989:  ROSE  and  Remote  Operations  Protocol 
(ROP),  as  specified  in  the  Remote  Operations  Part  1 :  Model  Notation  and  Service 
Definition  (ROSES)  and  the  Remote  Operations  Part  2:  Protocol  Specification 
(ROSEP),  and  as  modified  by  the  NMSIG  agreements  clause  6.5. 

L  ISO/IEC  10165-1:1993:  SMI. 

m.  ISOAEC  10165-2:1992:  DMI. 

n.  ISOAEC  10165-4:1992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

o.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.3  and  5.3.2,  if  message  handling  functionality  is  required. 

p.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
Agreements),  clause  13.7,  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

q.  Open  Software  Foundation  Distributed  Computer  Environment  (DCE):  Remote 
Procedure  Call  (RPC)  Service  Definition. 
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r.  Plan  to  use  IEEE  1327  Object  Management  API,  or  X/Open's  XOM  (on  which 
1327  is  based)  to  simplify  the  management  of  networked  managed  resources  in  a 
CMIP  environment  (See  system  management  APIs  BSA  in  part  8  for  more 
information.) 

s.  RFC  1006: 1 987 :  ISO  transport  services  on  top  of  the  TCP:  version  3  (IAB  Std 
35). 

3.9.S.5.6  Recommendations.  All  new  systems  and  systems  undergoing  major  upgrades  should 
use  the  Internet  Architecture  Board  (IAB)  STD  15,  SNMP  (RFC  1 157).  Those  persons 
conducting  procurements  that  involve  IAB  standards  should  review  the  latest  version  of  the  LAB 
official  protocol  standards  list  to  ensure  that  the  appropriate  RFCs  are  specified. 

The  PM  should  plan  to  use  CMIS/CMIP  for  OSI/GOSIP  networks  and  existing  TCP/IP 
networks,  because  SNMP  does  not  have  the  required  functionality  to  manage  distributed 
networks  and  is  very  expensive  to  maintain. 

Until  environments  become  distributed,  SNMP  is  a  suitable  solution  for  stand-alone  local  area 
networks. 

The  PM  also  should  plan  to  use  either  X/Open's  XMP  or  OSF's  CM-API  (they  are  the  same)  as  a 
common  API  to  CMIP  and  SNMP.  (See  the  system  administration  and  management  APIs  BSA  in 
part  8  for  more  information). 

The  CMOT  users,  vendors,  and  applications  should  be  aware  of  some  of  the  functional  differences 
between  OSI  managed  systems  and  Internet  agents  because  CMIS/CMIP's  more  sophisticated  and 
additional  features  may  be  difficult  to  map  reliably  to  TCP/IP  and  SNMP. 

A  common  protocol  API  should  be  used  to  access  CMIP  and  SNMP.  X/Open,  Unix 
International,  and  OSF  specify  the  same  API.  X/Open  and  Unix  International  call  the  API  "XMP" 
(X/Open  Management  Protocol);  OSF  calls  the  same  protocol  CM-API  (Consolidated 
Management  API).  Although  XMP  and  CM-API  provide  an  extra  call  specific  to  SNMP,  because 
the  SNMP  "GetNext"  function  call  does  not  work  in  an  OSI  environment,  the  consolidated 
management  protocol  API  provides  the  union  of  the  CMIP  and  SNMP  protocols  and  service 
primitives  consistently.  It  hides  some  of  the  differences  between  CMIP  and  SNMP.  For  most 
work,  programmers  and  system  managers  need  to  learn  only  a  single  syntax  to  access  both 
protocols. 
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3.9 .5.6  Managed  information  base.  Defined  objects  are  network  and  system  objects  that  can  be 
managed  by  a  network  or  system  management  application  and  are  stored  in  a  management 
information  database. 

3. 9.5.6. 1  Standards.  Table  3.9-23  presents  standards  for  managed  information  base. 

_ TABLE  3.9-23  Managed  information  base  standards _ 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAfi 

Structure  at  Management  Information  (SMI) 

Standard  16/RFC. 
U55/RFC-1212 

Mandated 

(Approved) 

IPC 

IAB 

Management  InfotnUion  Base 

Standard  17/RFC- 
1213 

Mandated 

(Approved) 

NPC 

TT2KF 

POSIX  System  Administration  •  Put  2:  Software 
Administration  (former  P1003.7.2) 

1387.2:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Structure  of  Management  Information  (SMI),  Part  1 : 
Management  Information  Model 

10165-1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Structure  of  Management  Information  (SMI),  Part  2: 
Definition  of  Management  Information  (DMI) 

10165.2:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Structure  of  Management  Information  (SMI),  Part  4: 
Guideline*  for  the  Definition  of  Managed  Objects  (GDMO) 

10165-4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

i mmmsmssmmm 

10165-5:1993 

Informational 

(Approved) 

NPC 

rpFP 

POSIX:  System  Administration  -  Part  3:  User  and  Group 
Administration 

1387.3:1996 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

CPC 

NMF 

Object  Class  Library  Supplement:  DIS  GDMO  Translation 

Forum  Library  - 
Volume  1  [Release 
1.0  Definition*  - 
Issue  1.3 

Informational 

(Approved) 

CPC 

NMF 

OSI/NM  Forum  Modeling  Principles  for  Managed  Objects 
Technical  Report 

NMF  Technical 
Report 

Informational 

(Approved) 

CPC 

IETF 

Management  Information  Base  for  SNMP  v2 

RFC  1450:1993 

Informational 

(Approved) 
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3.9J.6.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.9.5.6  .3  Standards  deficiencies.  ISO's  object  model  is  targeted  at  networking  and 
commi  -‘nations,  rather  than  general  system  management  It  is  built  around  CMIP  and  is  specific 
to  CMIS  services.  Among  other  things,  the  ISO  object  model  contains  concepts  such  as  the 
registration  of  objects  and  a  class  hierarchy.  This  registration  is  patterned  around  the  way 
CM1S/CMIP  objects  are  registered.  This  is  of  great  concern  to  network  management.  A  more 
generic  extensible  object  model  that  can  be  specialized  for  many  kinds  of  system  and  software 
objects  and  used  with  multiple  types  of  communication  systems  (e.g.,  remote  procedure  ca'ls)  is 
needed  for  system  management 

The  ISO  Guidelines  for  the  Definition  of  Managed  Objects  (GDMO)  formal  object  definition 
language  syntax  is  highly  specific  to  CMIP  and  uses  the  complex  ISO  CSI  ASN.l  notation.  This 
syntax  lends  itself  to  the  definition  of  objects  such  as  modems  and  other  network  devices.  It  is 
not  necessarily  suitable  for  defining  more  abstract  objects,  such  as  applications  and  operating 
systems,  which  are  needed  for  general  system  management 

The  OMG's  objects  lack  the  ability  to  have  more  than  one  interface.  This  ability,  called 
''allomorphism,"  is  taken  from  the  ISO  OS1  management  model's  allomorphism  requirement 
This  multiple  interface  ability  makes  it  possible  to  identify  different  classes  of  objects  (e.g„  classes 
A,  B,  and  C),  then  have  an  application  operate  on  an  instance  of  class  A  as  if  it  were  an  instance 
of  class  B  or  C.  Allomorphism  is  important  because  it  allows  the  definition  of  enhanced  versions 
of  a  managed  object  class  that  are  backward  compatible  with  previous  versions.  Migration  costs 
are  thereby  reduced. 

3.9.5.6.4  Portability  caveats.  Multiple  object  models  are  being  defined  by  various  organizations 
(e.g.,  ISO,  the  Object  Management  Group).  These  different  models  conflict  with  each  other. 
Among  other  things,  they  differ  in  the  way  they  represent  objects,  the  object  interfaces,  the 
targeted  application  domain,  and  the  targeted  types  of  objects. 

The  OMG  object  model,  on  which  the  OSF  object  model  is  based,  is  a  generic  one,  to  which 
extensions  can  be  added  to  specialize  objects  for  different  domains.  In  contrast,  the  ISO  object 
model  is  targeted  at  networking  and  communications.  It  is  built  around  CMIP  and  is  specific  to 
CMIS  services.  Although  CMIS/CMIP  is  supposed  to  accom  -odate  any  management  data,  until 
now,  the  focus  has  been  on  network  management. 

The  ISO,  NMF,  and  IEEE  P1387  distributed  system  administration  groups  define  their  managed 
objects  using  the  ISO  GDMO  definition  language.  OSF  is  using  its  Interface,  Inheritance, 
Implementation,  and  Installation  (I4DL)  definition  language,  which  is  based  on  the  OMG's 
Interface  Definition  Language  (IDL),  to  define  its  managed  objects.  Unfortunately,  the  GDMO, 
I4DL,  and  IDL  interfaces  defined  by  each  of  the  object  models  affect  the  basic  object  model 
(which  are  different  for  ISO,  OSF,  and  OMG)  and  make  it  difficult  to  use  one  object  model's  set 
of  interfaces  for  another. 
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3.9.5.6.5  Related  standards.  The  Object  Management  Group's  Interface  Definition  Language 
(IDL)  for  defining  generic  objects  is  related  to  object  definition  standards. 

3.9.5.6.6  Recommendations.  All  new  systems  and  systems  undergoing  major  upgrades  should 
use  the  Internet  Architecture  Board  (IAB)  STD  16  and  IAB  STD  17.  Those  persons  conducting 
procurements  that  involve  IAB  standards  should  review  the  latest  version  of  the  IAB  official 
protocol  standards  list  to  ensure  that  the  appropriate  RFCs  are  specified.  If  recommended 
standards  do  not  meet  system  requirements  or  are  cost  prohibitive,  standards  for  the  legacy 
systems  may  be  used,  as  long  as  interoperability  is  not  impacted.  The  use  of  legacy  system 
standards  may  require  a  waiver  from  the  appropriate  authority. 
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3.9 .5.7  Event  management.  Event  management  and  notification  services  allow  system  managers 
and  system  administrators  to  be  informed  that  a  predefined  system  or  network  event  of  interest 
(e.g.,  additional  resources  needed)  has  occurred,  so  that  the  event  may  be  managed  in  a 
predefined  way  that  prevents  network  or  system  problems.  Event  management  is  related  closely 
to  fault  and  performance  management,  in  that  each  of  these  services  could  make  use  of  event 
management  to  log,  track,  and  provide  alerts  based  on  relevant  events. 

3. 9.5.7. 1  Standards.  Table  3.9-24  presents  standards  for  evc.it  management. 


TABLE  3,9-24  Event  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  1  (Adopu  ISO  Profile  Set*  1 1 183-X,  12059- 
X,  end  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

GPC 

NIST 

Stable  Implementation  Agreement*  for  Open  Sytfem 
Environment*,  Ver.  8,  Ed.  1 

Special  Pub.  500- 
224:12/94 

Informational 

(Approved) 

IPC 

iso/mc 

OSI  Syitem*  Management,  Put  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Portable  Operating  Syitem  Interface  (POSIX)  Part  I : 
Syitem  API  (Replace*  ISO  9945- 1 : 1990  and  incorporate* 
IEEE  1003.1b,  1003.1c,  and  1003.10 

9945-1:1996 

Informational 

(Approved) 

NPC 

mpB 

Portable  Operating  Syitem  Interface  (POSIX)  •  Part  I : 
Syitem  Application  Program  Interface  (API)  Amendment 

1:  Realtime  Extension  (C  language) 

1003.1b:  1993 

Informational 

(Approved) 

* 

AvsQatta,  and  Sepdoeabie  SyttMM  (3RAS3)  {C 

- ViNU.lt. 

fcfeMMfaNl 
<*— «> 

i 

3.9.5.7.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Banyon  Systems'  Network  Event  Logger  (from  Wang  Laboratories)  on  which 
OSF's  Event  Notification  Component  is  based. 

b.  Banyon  Systems'  PC  library  for  the  Network  Event  Logger,  which  filters  and  logs 
PC  events  locally  and  sends  them  to  a  Network  Event  Logger  server  on  a  host 
system  for  further  processing.  The  OSF  DME's  PC  Error  Logging  Component  is 
based  on  this  Banyon  Systems'  PC  library. 

3.9.5.7.3  Standards  deficiencies.  None  of  the  event  notification  components  in  any  of  the 
consortia  management  systems  are  compatible  with  the  IEEE  P1003.1b  specifications  for  event 
notification.  OSF  DME  event  management  is  intended  to  be  used  as  the  basis  for  commercial 
management  systems,  but  is  not  currently  supported  by  any  products. 

3.9.5.7.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 
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3.9S.7S  Related  standards.  The  following  standards  are  related  to  event  management  and 
notification  standards: 

a.  ISO/IEC  DIS  11578.2:  RPC  (P;-vIsces  DIS  1 1578  PT  1  Thru  PT4.) 

b.  NIST  APP  -  Special  Pub.  500-230:  1 995. 

c.  OSF:  Distributed  Computing  Environment  (DCE)  Remote  Procedure  Call 
Component 

d.  USL/Sun  Microsystems:  Open  Network  Computing  (ONC)  Remote  Procedure 
Call  (RPC)  Component 

e.  NISTFIPS  179-1:1995:  Government  Network  Management  Profile  (GNMP). 

f.  ISO/IEC  9596- 1 : 1991 :  OSI CMIP,  Part  1 :  Specification. 

g.  IAB:  RFC  1157:  SNMP. 

3.9.S.7.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 
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3.9.5 .8  Input/Output  control.  (This  BSA  appears  in  both  part  8  and  part  9.)  Input/Output  (I/O) 
control  standards  include  services  such  as  device  initialization,  device  attachment,  asynchronous 
operation,  error  notification,  raw  I/O,  and  other  services  needed  to  implement  logical  device 
drivers  in  a  system. 

Input/output  control  enables  control  of  different  media  devices  over  the  network  through 
software.  The  media  devices  include  videocassette  recorders,  laser  disc  players,  video  cameras, 
CD  players,  and  so  on.  Control  capabilities  may  be  available  on  the  workstation  through  a 
graphical  user  interface  (GUI).  They  are  similar  to  the  controls  on  the  device,  such  as  play, 
record,  reverse,  eject,  and  fast  forward.  Input/output  control  is  important  because  it  enables  the 
operator  to  control  video  and  audio  remotely  without  requiring  physical  access. 

3.9.5. 8.1  Standards.  Table  3.9-25  presents  standards  for  input/output  control. 


TABLE  3.9-25  Input/Output  control  standards 


Standard 

Type 

Sponsor 

IPC 

ISO/IEC 

CPC 

X/Open 

CPC 

X/Open 

GPC 

NIST 

NPC 

IEEE 

NPC 

IEEE 

W 

Single  Unix  Specification  (Spec  1 170),  Syitem  Interface 
Definition*,  Iuue  4,  Vernon  2  (pert  of  XPG4) 


Single  Unix  Specification  (Spec.  1 170),  Syitem  Interface* 
and  Header*,  Iuue  4,  Venion  2,  (Part  of  XPG4) 


Portable  Operating  Syitem  interface  (POSDC)  •  Part  1 : 
Syitem  Application  Program  Interface  (API)  Amendment 
I:  Realtime  Extention  (C  bu,  j’ut) 


POSIX  Part  1:  Syitem  Application  Program  Interface  1003. 1 i:  1995 

(API)  -  Amend:  Technical  Corrigenda  to  Real  Time 
Exteniion  1C  Language] 


pim  U 


3.9.S.8.2  Alternative  specifications.  The  following  specifications  are  also  available: 


a.  Berkeley  4.2/4.3  Unix. 

b.  OSF:  OSF/1  (product  implementation). 
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3.9.5.8J  Standards  deficiencies.  POSIX.  1  provides  basic  input/output  primitives,  but  lacks  the 
generalized  services  needed  to  implement  device  drivers  for  many  types  of  devices.  POSIX.  lb 
provides  support  for  asynchronous  and  synchronized  I/O,  but  also  lacks  generalized  services 
needed  to  implement  device  drivers  for  many  types  of  devices. 

3.9.5.8.4  Portability  caveats.  The  "ioctl"  function,  which  is  associated  with  the  control  of  an 
asynchronous  device  (including  terminal  characteristics)  has  been  identified  repeatedly  as  a  source 
of  portability  problems.  It  is  an  old  system  call,  and  during  the  many  years  it  has  been  in  Unix, 
several  variants  have  evolved.  The  differences  appear  at  low  levels.  However,  it  is  not  always 
easy  to  spot  these  differences,  because  each  "ioctl"  is  defined  loosely  and  makes  its  own 
assumptions.  As  networking  becomes  more  common,  the  device  drivers  executing  some  code 
may  be  located  across  a  network,  remote  from  the  source  of  the  system  call.  The  many  variants 
and  interpretations  of  "ioctl,"  complicate  networking  because  the  same  "ioctl"  system  call  possibly 
cannot  be  used  across  a  network  to  control  a  remote  peripheral.  For  example,  the  SVID  version 
of  "ioctl"  looks  like  a  completely  different  call.  Because  of  the  difficulty  in  reaching  agreement  on 
a  standardized  version  of  the  "ioctl,"  the  POSIX  standards  groups  eliminated  "ioctl"  from  the 
standard  early.  Because  the  POSIX.  1  b  real  time  group  believes  that  most  devices  communicate 
using  "ioctl,"  there  was  a  move  to  reinstate  and  standardize  "ioctl"  in  the  P1003.1b  standard.  The 
final  result,  however,  was  the  incorporation  of  specific  "tc"  (terminal  control)  functions  to  replace 
each  "ioctl"  function. 

The  use  of  "ioctl"  calls  to  set  certain  terminal  modes  causes  problems  because  a  single,  standard 
terminal  interface  or  portable  mechanism  to  set  the  modes  of  an  asynchronous  terminal  does  not 
exist.  Such  a  standard  has  not  been  defined,  because  it  would  require  the  "raw"  (unprocessed) 
and  "cooked"  (processed)  modes  to  be  defined.  Defining  these  would  create  other  problems. 
However,  not  defining  them  could  cause  application  codes  to  be  written  in  a  nonportable  way. 

The  SVID  and  XPG  support  the  "ioctl"  call  as  part  of  their  device  service  interfaces.  In  practice, 
this  support  is  different  on  every  different  implementation  of  these  specifications.  The  "ioctl" 
function,  while  deprecated  for  asynchronous  terminal  control  in  favor  of  the  POSIX.  1  "tc" 
functions,  is  still  required  to  control  other,  less  common  device  types.  Unfortunately  there  is  no 
standard  for  programmatic  control  of  video  cameras,  etc.,  even  though  every  system  which 
supports  such  a  device  will.provide  the  basic  control  functionality  needed  in  some  way. 

3.9.5.8.5  Related  standards.  The  following  standards  are  related  to  input/output  control  or 
input/output  control  standards: 

a.  ISO  10164-7:  Security  Management. 

b.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

c.  IEEE  1003.2d:  1994:  POSIX  Batch  Environment  Amendments. 

d.  IEEE  P1201.1:  Uniform  API-GUI. 
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e.  NIST  FIPS  179- 1 : 1995:  GNMP  (Government  Network  Management  Protocol): 
Authentication. 

f.  MIT  Consortium:  X  Window  System. 

3.9.5.8.6  Recommendations.  The  mandated  standards  are  recommended  for  input/output 
control.  The  operating  system  standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945- 
1:1990,  IEEE  1003.16:1993,  IEEE  1003.1c:1995,  and  IEEE  1003.1i:1995)  are  all  incorporated  in 
the  new  ISO/IEC  9945- 1 : 1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should 
also  be  consulted.  It  adopted  ISO  9945- 1 : 1 990  and  is  still  applicable  to  the  1 996  version.  It 
specifies  read/write  functionality.  The  "tc-functions"  were  incoduced  into  POSIX.l  to  solve 
portability  issues  arising  from  "ioctl"  calls.  X/Open  SUS  covers  all  the  core  POS1X  functions. 
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3.9.6  Fault  monitoring.  Fault  monitoring  services  allow  a  system  to  react  to  the  loss  or 
incorrect  operation  of  system  components  at  various  levels. 

3.9.6.1  Software  safety.  (This  BSA  appears  in  both  Part  2:  Software  Engineering  and  Part  9: 
System  Management)  These  standards  provide  procedures  for  identifying  as  safety-critical  those 
CSCIs  or  portions  thereof  whose  failure  could  lead  to  a  hazardous  system  state  (one  that  could 
result  in  death,  injury,  loss  of  property,  or  environmental  harm).  The  developer  shall  develop  a 
safety  assurance  strategy,  including  both  tests  and  analyses,  to  assure  that  the  requirements, 
design,  implementation,  and  operating  procedures  for  the  identified  software  minimize  or 
eliminate  the  potential  for  hazardous  conditions.  The  objective  is  to  eliminate  hazards,  and  reduce 
the  associated  risk  to  a  level  of  acceptability  to  the  managing  activity. 

3.9.6.1.1  Standards.  Table  3.9-26  presents  standards  for  software  safety. 


TABLE  3.9-26  Software  safety  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ili 

GPC 

DOD 

System  Safety  Program  Requirement! 

MIL-STD-S82C: 

1996 

Adopted 

(Approved) 

NPC 

Software  Safety  Plant 

1228:1994 

Informational 

(Approved) 

3.9.6.1.2  Alternative  specifications.  No  other  specifications  are  known. 

3.9.6. 1J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.6.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.6. 1.5  Related  standards.  None. 

3.9.6.1.6  Recommendations.  MIL-STD-882C  is  recommended. 
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3.9.6 2  Database  recovery.  (This  BSA  appears  in  both  part  4  and  part  9.)  Database  recovery 
refers  to  the  ability  to  detect  a  failure  in  a  system,  recover  from  failure,  and  permit  a  slave  copy  to 
become  a  master  copy,  assuring  data  integrity  and  consistency. 

3.9.6.2.1  Standards.  Table  3.9-27  presents  standards  for  database  recovery. 


TABLE  3.9-27  Database  recovery  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/EC 

OSI  Service  Definition  for  the  Commitment,  Concurrency, 
and  Recovery  (CCR)  Service  Element 

9804:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Protocol  Specification  for  (he  Commitment, 
Concurrency,  and  Recovery  (CCR)  Service  Element 

9805:1990 

Informational 

(Approved) 

3.9.6.2.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.9.6.2.3  Standards  deficiencies.  Deficiencies  in  database  recovery  standards  are  unknown. 

3.9.6.2.4  Portability  caveats.  At  present,  CCR  is  not  widely  implemented,  although  most 
vendors  intend  to  implement  it  Therefore,  one  should  make  no  assumptions  about  the  degree  of 
portability  and  interoperability  existing  for  any  database  recovery  utilities. 

3.9.6.2.5  Related  standards.  The  following  standards  are  related  to  database  recovery  or 
database  recovery  standards: 

a.  ISO/IEC  10026  Parts  1,  2,  and  3:  Distributed  Transaction  Processing  (DTP) 
protocol 

b.  X/Open  XA  Interface  specification,  which  includes  CCR's  two-phase  commitment 

3.9.6.2.6  Recommendations.  If  CCR  is  desired  (and  it  is  necessary  for  multivendor,  distributed 
database  and  distributed  transaction  processing),  it  must  be  referenced  specifically  in  procurement 
specifications.  Otherwise,  vendors  probably  will  propose  products  that  do  not  meet  this 
specification. 

For  the  greatest  portability,  design  applications  as  if  CCR  were  not  present. 


April  7,  1997 


3.9-62 


Version  3.1 


Information  Technology  Standards  Guidance 


System  Management  Services 


3.9.63  Recover;  and  restart  services  for  long  running  transactions.  (This  BSA  appears  in 
both  part  4  and  part  9.)  Checkpoint  and  n  start  is  provided  for  interactive  transactions  on 
centralized  systems  via  the  SQL  "commit"  and  "rollback"  commands,  and  for  short-running 
transactions  on  distributed  systems  via  the  2-Phase  Commit  specified  in  the  ISO  CCR  standard. 
However,  long  running  transactions  require  standardized  checkpointing,  restarting,  and  migration 
services  and  interfaces  to  prevent  the  loss  of  the  transaction  if  a  system  fails  or  shuts  down.  Two 
APIs  must  be  standardized  for  this  purpose.  One  will  allow  application  control  of  the  checkpoint. 
The  other  will  allow  the  transaction  manage!  to  control  the  checkpointing  and  restart  activity  over 
a  range  of  heteroge.  aous  resource  managers. 

3.9.6.3.1  Standards.  Table  3.9-28  presents  sta.jards  for  recovery  and  restart  services  for  long 
running  transactions. 


TABLE  3.9-28  Recovery  and  restart  services  for  long  running  transactions  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IEEE 

1003.2(1:1994 

Informational 

(Approved) 

11  !!|iiii!|!|; 

• . . 

j.9.6.3.2  Alternative  specifications.  The  following  specifications  are  also  available; 

a.  USL:  Tuxedo 

b.  Transarc:  Encina 

c.  NCR:  Top  End 

3.9.6.3J  Standards  deficiencies.  Based  on  a  requirement  from  the  P1003. 1 5  Batch  Queuing 
Extensions  Standards  Group,  the  POSDC.l  revision  will  specify  application  control  of 
checkpointing.  But  this  specification  is  geared  to  batch  environments,  and  does  not  address  the 
transaction  manager's  control  of  checkpoint,  restart,  or  migration  of  services  needed  for  a 
transaction  processing  environment  This  need  is  not  being  addressed  other  than  by  dc  facto 
solutions. 

1003.2d  sp  -cifies  some  capabilities  needed  for  checkpointing  and  restart  in  batch  environments, 
but  as  a  standard  geared  to  batch  environments,  it  dc  ,\>  not  address  the  transaction  manager's 
control  of  checkpoint,  restart,  or  migration  of  services. 

3.9.6.3.4  Portability  caveats.  Wi'hout  standardized  interfaces  to  allow  application  control  of 
checkpointing  and  Uansaction  manager's  control  of  checkpointing  and  restart  activity,  portability 
and  interoperability  across  heterogeneous  resource  managers  are  nonexistent,  except  for  short- 
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running  transactions  (which  are  controlled  via  SQLs  ‘commit"  and  "rollback"  commands  and  via 
ISO's  OCR  standard). 

3.9.6.3.5  Related  standards.  The  following  standards  are  related  to  recovery  and  restart  services 
or  standards: 

a.  ISO  9041-1 :  Basic  Class  Virtual  Terminal  Protocol  Specification 

b.  ISO  9075: 1992:  SQL  3rd  edition 

c.  IEEE  1003. lb:  1993:  Real-Time  Extension  to  POSDC 

d.  IEEE  1003.  lc:  1995:  Threads  Extension  to  POSIX 

3.9.63.6  Recommendations.  There  is  no  recommendation  for  recovery  and  restart  services. 
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3.9.6.4  Network  error  recovery.  These  are  procedures  for  the  detection  and  reconstitution  of 
corrupted  data,  packet  data  units,  and/or  datagrams. 


3.9.6.4.1  Standards.  Table  3.9-29  presents  standards  for  network  error  recovery. 


TABLE  3.9-29  Network  error  recovery  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

IAB 

Tn«aita»n  Control  Protocol 

Standard  7/RPC- 

793 

Mandated 

(Approved) 

IPC 

LAB 

Hoet  Requirements 

Standard  3/RPC- 
1122*FC-1123 

Mandated 

(Approved) 

IPC 

IAB 

The  Podtt-to-Potot  Protocol  (PPP) 

Standard  51/RFC 
1661 

Mandated 

(Approved) 

GPC 

DOD 

Transport  Profile:  Reliable  End  System  Transport  for  DOD 
Communications 

MIL-STD-2045- 
14500  Part 

1:  March  1994 

Informational 

(Approved) 

GPC 

DOD 

MIL-STD-2045- 
14502  Part  3  July 
1994 

Informational 

(Approved) 

GPC 

DOD 

Transport  Profile:  Balmood  Point-to-Point  Difilal  Data 

Circuit 

M1L-STD-2045- 
14500  Part 
2:March  IW 

Informational 

(Approved) 

GPC 

DOD 

Transport  Profile:  Subnetwork  for  rat  Unbalanced  Data 
Link 

MIL-STD-2045- 

14500  Part 

3:  March  1994 

Informational 

(Approved) 

1  GPC 

1 

DOD 

Interns*  Transport  Profile  for  DOD  CommaecalKau: 
Point- to- Point  Links 

MIL-STD-2045- 
14502  Part  2  July 
1994 

InfomutiotMl 

(Anjroved) 

_ 

■gllll 

Icdi 

3.9.6.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.9.6.4J  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.9.6.4.4  Portability  caveats.  Connection-oriented  transport  has  five  levels  of  service  that  deal 
with  reliability.  These  classes  do  not  interoperate.  Applications  using  different  classes  of 
transport  service  will  have  portability  problems. 

The  X.25  equipment  conforming  to  different  specification  dates  (e.g.,  1980,  1984,  1988,  1992) 
can  have  interoperability  problems. 

3.9.6.4.5  Related  standards.  There  are  no  related  standards. 

3.9.6.4.6  Recommendations.  Error  recovery  is  one  of  the  functions  supported  by  the 
Transmission  Control  Protocol  (TCP).  The  TCP  should  be  used  as  specified  in  the  1AB  STD  7. 
The  IAB  STD  3  identifies  and  corrects  errors  in  the  TCP. 
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MIL-STD-2045- 14500-01  is  recommended  for  legacy  systems  interoperability.  It  specifies  the 
details  necessary  to  meet  DOJ  requirements  for  connection-oriented  transport  service  over  a 
connectionless  network  service.  It  uses  class  four  transport  protocol  as  one  of  its  base  standards. 
It  is  an  error  detection  and  recovery  class  that  assumes  the  underlying  network  service  is 
unreliable.  MIL-STD-2045-14500  parts  2  and  3  are  recommended  for  legacy  systems 
interoperability.  Use  of  LAPB  for  Balanced  Point  to  Point  Digital  Data  Circuit  should  comply 
with  MIL-STD-204S- 14500-02.  For  an  Unbalanced  link,  LAPB  should  be  used  as  specified  in 
M1L-STD-2045- 14500-03. 

If  recommended  standards  do  not  meet  system  requirements,  or  are  cost  prohibitive,  standards  for 
the  legacy  systems  may  be  used  as  long  as  interoperability  is  not  impacted.  The  use  of  legacy 
systems  standards  may  require  a  waiver  from  the  appropriate  authority.  MIL-STD-2045-44000  is 
an  emerging  standard.  It  uses  TCP  and  UDP  with  enhancements  to  meet  specific  requirements 
for  high-stress  resource  constrained  environments. 
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3.9.6.S  Fault  management.  (This  BSA  appears  in  part  3  and  part  9.)  Fault  management 
services  allow  a  system  to  react  to  the  loss  or  incorrect  operation  of  system  components.  Fault 
management  services  encompass  services  for  fault  detection,  isolation,  diagnosis,  recovery,  and 
avoidance.  Fault  management  may  make  use  of  event  management  facilities.  In  practice,  fault 
management  and  performance  management  products  often  incorporate  event  management 
functions. 

3.9.6.5.1  Standards.  Table  3.9-30  presents  standards  for  fault  management 


TABLE  3.9-30  Fault  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  1  (Adopt*  ISO  Profile  Set*  1 1 183-X,  12059- 
X.  md  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 

IPC 

•«v^c 

OS I  Syrian*  Management,  Put  4:  Alarm  Reporting 
Function 

10164-4:1992 

Informational 

(Approved) 

IPC 

15.'  '  ... 

10164*5:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

r-  ill '  tunu  Management,  Part  6:  Log  Control  Function 

10164*6:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

■i1 sat  Management,  Prut  12:  Teat  Management 
Function 

10164-12:1994 

Informational 

(Approved) 

NPC 

SAE 

General  Open  Architecture  (GOA)  Framework 

AS  4893 

(Committee  AS-5) 

Informational 

(Approved) 

. 
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3.9.6J5.2  Alternative  specifications.  The  following  specifications  for  network  fault  reporting  are 
available: 

a.  Banyon  Systems's  Network  Event  Logger  (originally  developed  by  Wang 
Laboratories),  on  which  OSFs  DME  event  services  and  logging  services  are  based. 

b.  Gradient  Technologies:  PC  Event  system  integrated  with  a  Banyon  Systems-based 
Network  Event  Logger  PC  library  and  a  PC  Ally  server  on  which  OSF  has  based 
its  PC  event  and  logging  component. 
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3.9.6S3  Standards  deficiencies.  The  present  ISO  10164-4,  "Alarm  Reporting  Function,' " 
10164-6,  "Log  Control  Function,"  10164-5,  "Event  Report  Management  Function,"  10164-12, 
"Test  Management  Function,”  and  10164-14,  "Confidence  and  Diagnostic  Testing  Service" 
standards  were  designed  with  network  configuration  in  mind.  Theoretically,  these  standards 
should  be  able  to  be  used  for  configuration  management  of  any  computer  system.  Little  work  has 
been  done  in  this  area,  either  in  standards  groups  or  in  products.  Therefore,  exactly  how  these 
standards  should  be  used  in  host  management  is  undetermined. 

Although  several  standard  libraries  of  object  classes  that  allow  a  common  view  of  network 
resources  and  fault  management  of  network  resources  are  planned,  few  are  available  or 
sufficiently  complete.  For  example,  these  library  specifications  have  incomplete  object  definitions 
for  modems,  OSI  routers,  and  transport  connections.  Based  on  U.S.  Federal  Government  needs 
(as  shown  by  NIST  surveys),  the  GNMP  added  more  object  class  specifications  and  definitions. 
These  include  the  following  objects:  LANs,  X.25  Wide-Area-Networks  (WANs),  Integrated 
Services  Digital  Network  (ISDN),  Fiber  Distributed  Data  Interface  (FDDI),  modems,  bridges, 
links,  and  a  rudimentary  capability  to  manage  OSI  routers  and  transport  connections. 

Phase  2  GNMP  objects  also  will  include  protocol  software  (layers  3-7),  routers,  terminal  servers, 
Message  Transfer  Agents  (MTAs),  Private  Branch  Exchange  (PBXs),  and  circuit  switches. 

Versions  1 .0  and  2.0  of  the  GNMP  currently  specify  only  network  management  capabilities.  Not 
until  Version  3.0  will  the  GNMP  specify  the  management  information  required  for  general  system 
management,  such  as  host  computer  configuration  and  management,  operating  systems,  and 
database  management  systems. 

The  present  ISO  standards  and  GNMP  specifications  require  ISO  CMIS/CMIP  for  the 
communications  of  management  information  and  ISO  OSI  networking  protocols.  Plans  are  for 
the  GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with  SNMP  also. 
One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 

Fault  management  should  make  use  of  general  event  management  such  as  OSF  DME  event 
services,  but  most  products  currently  implement  their  own  event  management  facilities. 

Finally,  standards  are  needed  for  problem  reporting  and  tracking,  diagnostic  standards  for 
hardware  and  software,  and  fault  isolation. 

3.9.6.5.4  Portability  caveats.  Portability  problems  with  existing  standards  are  unknown. 

3.9.6.5.5  Related  standards.  The  following  standards  are  related  to  fault  management  or  fault 
management  standards: 

a.  ISO/IEC  7498-4:1989:  Management  Framework. 
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b.  ISO/1EC  857 1 : 1988:  File  Transfer,  Access,  and  Management  (FT AM),  as 
specified  in  GOSIP  Version  2  Sections  4.2.7 .2  and  5.3. 1 ,  if  File  transfer,  Access, 
and  Management  functionality  are  required. 

c.  ISO/IEC  8650: 1988:  Association  Control  Service  Element  (ACSE),  as  specified  in 
GOSIP  Version  2,  Section  4.2.7. 1,  as  modified  by  the  NMSIG  agreements  in  Part 
18  of  the  OIW  Implementors  Agreements. 

d.  ISO/IEC  8824: 1990:  Specification  of  Abstract  Syntax  Notation  1  (ASN.  1). 

e.  ISO/IEC  8825: 1990:  Specification  of  Basic  Encoding  Rules  for  ASN.l. 

f.  ISO/IEC  9041:1990:  (OSI  Virtual  Terminal),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7.2  and  5.3. 1,  if  virtual  terminal  functionality  is  required. 

g.  ISO/IEC  9072: 1989:  Remote  Operations  Service  Element  (ROSE),  as  specified  in 
the  Remote  Operations  Part  1 :  Model  Notation  and  Service  Definition  (ROSES), 
and  the  Remote  Operations  Part  2:  Protocol  Specification  (ROSEP),  and  as 
modified  by  the  NMSIG  agreements  clause  6.5. 

h.  ISO/IEC  9595: 1991:  Common  Management  Information  Service  (CMIS). 

i.  ISO/IEC  9596:1991:  Common  Management  Information  Protocol  (CMIP). 

j.  ISOAEC  10165-1:1993:  Structure  of  Management  Information  (SMI). 

k.  ISO/IEC  10165-2: 1992:  Definition  of  Management  Information  (DMI). 

l.  ISOAEC  10 1 65-4: 1 992:  Guidelines  for  the  Definition  of  Managed  Objects 
(GDMO). 

m.  ISOAEC  DIS  1 1578.2:  Remote  Procedure  Call. 

n.  CCITT  X.400  Message  Handling  System  (MHS),  as  specified  in  GOSIP  Version  2 
Sections  4.2.7. 3  and  5,3.2,  if  message  handling  functionality  is  required. 

o.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  - 
Language  Independent  Specification. 

p.  IEEE  1327: 1993:  OSI  Abstract  Data  Manipulation  (Object  Management)  API  -  C 
Language  Binding. 

q.  NIST  OSI  Implementors  Workshop  (OIW)  Implementor  Agreements  relating  to 
the  Presentation  and  Session  layers,  as  specified  in  Part  5  (Upper  Layer 
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Agreements),  clause  13.7  of  the  OIW  Stable  Implementation  Agreements  for  OSI 
Protocols  Version  3  (NIST  Special  Publication  500-224). 

r.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
Internets  based  on  TCP/IP. 

s.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

t.  Internet  RFC  1 158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

u.  X/Open:  OSI-Abstract-Data  Manipulation  API  (XOM)  (Object  Management). 

3.9.6.S.6  Recommendations.  To  build  or  procure  fault  management  applications,  users  must 
identify  the  system  management  functions  that  are  applicable  to  their  requirements.  Then  they 
must  identify  the  various  specifications  within  the  ISO  10164  and  10165  standards  related  to 
these  requirements.  Finally,  they  must  specify  the  requirements  and  the  related  standards  in  the 
RFP. 

The  OMNIPoint  program  defines  a  collection  of  specifications  for  the  management  of  network 
and  distributed  systems  using  open  standards  and  specifications.  It  replaces  FIPS  179  (GNMP)  in 
Version  3.0  of  the  NIST  Application  Portability  Profile. 
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3.9.6.6  Storage  device  management  (This  BSA  appears  both  in  part  8  and  part  9.)  Storage 
device  management  is  familiar  to  most  people  as  “Logical  Volume  Management.'1  With  logical 
volume  management,  a  logical  volume  manager  provides  disk  partition  flexibility  by  allowing  the 
disk  partitions  to  grow  automatically  as  the  system  runs,  and  by  allowing  files  to  span  physical 
volumes.  This  allows  a  given  file  to  be  larger  than  any  one  disk.  This  flexibility  is  possible 
because  the  logical  volume  manager  manages  the  disk  space  by  creating  what  it  calls  “logical 
volumes."  The  logical  volume  manager  determines  the  correspondences  between  the  logical 
volumes  and  the  actual  physical  volumes.  A  logical  drive  is  an  allocated  part  of  a  physical  drive 
designated  and  managed  as  an  independent  unit.  Hierarchical  storage  management  and  archiving 
addresses  the  ability  to  handle  different  levels  of  storage  transparently,  such  as  disks,  tapes,  and 
juke  boxes. 

3.9.6.6.1  Standards.  Table  3.9-31  presents  standards  for  storage  device  management. 


TABLE  3.9-31  Storage  device  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

QSF 

DiitribUed  Computing  Environment  (DCE)  Diitributed 
File  Service  (DFS) 

DCE  1.1  DFS:1994 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphic*  Device  Interface, 
Volume  1  Mi cro loft  Win32  Programmers'  Reference 
Manual,  1993,  Microsoft  Proas 

Win32  API» 

Mandated 

(Approved) 

CPC 

QSF 

DCE  1.1  NFS:  1994 

Informational 

(Approved) 

CPC 

QSF 

OSF/I  Operating  Syitem 

OSF/1  O.S. 

Informational 

(Approved) 

— cie- 

3.9.6.6.2  Alternative  specifications.  Future  releases  of  SVR4  will  support  the  Logical  Volume 
Manager,  but  no  other  alternative  specifications  are  available. 

3.9.6.6.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.6.6.4  Portability  caveats.  Portability  caveats  are  unknown  at  this  time. 

3.9.6.63  Related  standards.  No  standards  are  related  to  storage  device  management. 

3.9.6.6.6  Recommendations.  Open  Software  Foundation's  Distributed  File  Service  is 
recommended.  Logical  volume  managers  are  extremely  valuable,  as  many  system  managers  know 
who  have  had  to  back  up  a  system,  take  it  down,  repartiation  it  to  accommodate  the  growth  of 
applications  and  data  in  certain  partitions,  and  restore  the  system,  only  to  do  the  same  thing 
months  later.  The  logical  volume  manager  eliminates  this  problem  by  allowing  partitions  to  grow 
dynamically. 
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3.9.6.7  Backup  and  restore.  (This  BSA  appears  both  in  part  8  and  part  9.)  Backup  and  restore 
standards  provide  facilities  and  interfaces  to  save  data  as  a  precaution  to  system  failure  and 
restore  the  system  to  a  previous  data  state  after  failure. 

3.9.6.7.1  Standards.  Table  3.9-32  presents  standards  for  backup  and  restore. 


TABLE  3.9-32  Backup  and  restore  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Portable  Operating  System  Interface  (FOSIX)  Part  1: 
Syttem  API  (Replace*  ISO  9945- 1:1990  and  incorporates 
IEEE  1003.1b.  1003.1c,  and  1003.  li) 

9945.1:1996 

Mandated 

(Approved) 

IPC 

1SO/THC 

Information  Technology  -  Portable  Operating  Syttem 
Interface  (POSK)  -  Put  2:  Shell  and  Utilities  (ai  profiled 
by  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification  (Spec  1 170)  Command*  and 
Utilitiei,  lime  4,  Vernon  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

CPC 

NIST 

FIPS  PUB  151- 
2:1993 

Informational 

(Approved) 

NPC 

ANSI 

X3.  39-1986 
(R1992) 

Informational 

(Approved) 

NPC 

ANSI 

Recorded  Magnetic  Tape  for  Information  Interchange 
(6250  cpi,  Group-Coded  Recording) 

X3.  54- 1986 
(R1992) 

Informational 

(Approved) 

CPC 

OSF 

OSF/1  Operating  Syttem 

OSF/1 0.S. 

Informational 

(Approved) 
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3.9.6.7.2  Alternative  specifications.  The  "dd"  utility  is  useful  for  data  copy  with  optional 
conversion  that  promotes  portability,  (e.g.,  ASCII  to  EBCDIC)  or  for  record  conversion  with 
discrete  record  sizes,  or  multiple  sector  reads/writes  to  disk.  The  Berkeley  Unix  "dump" 
command  is  also  available.  The  OSFs  OSF/1  "tar"  and  "cpio"  utilities  and  USG's  System  V 
Release  4  (SVR4)  are  also  av.  iable. 

3.9.6.73  Standards  deficiencies.  Although  the  "tar"  and  "cpio"  commands  can  be  used  to  back 
up  disks,  they  are  very  limited  in  capability,  "tar"  and  "cpio"  are  copy  commands.  These 
commands  do  not  perform  incremental  backups.  Furthermore,  "tar"  does  not  span  multiple  disks. 
No  Ada  bindings  exist  for  distributed  backup  and  restore  standards. 

3.9.6.7.4  Portability  caveats.  The  "ustar"  format  is  an  extension  of  the  historical  "tar"  archive 
format  and,  as  such,  may  be  read  by  historical  implementation  of  the  "tar"  command.  The 
POSIX.2  "pax"  command  has  been  developed  as  a  replacement  for  both  "tar"  and  "cpio" 
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commands.  It  can  read  and  write  "ustar"  and  "cpio"  archives,  and  most  implementations  have 
been  extended  to  read  historical  "tar"  format  archives  as  well. 

The  "cpio"  command  can  produce  two  different  types  of  archives:  "character"and  "binary."  The 
binary  archives  are  non-portable,  and  cannot  be  read  except  on  the  same  platform  on  which  they 
were  produced.  POSIX  documents  only  the  character  "cpio"  format,  and  the  "pax"  command  is 
only  guaranteed  to  be  able  to  read  the  character  format. 

The  Berkeley  Unix-based  set  of  "backup"  commands  (e.g.,  “dump"  and  "rdump")  are  not  the 
same  as  the  backup  commands  based  on  System  V  (SVID)  (e.g.,  "backup,"  "bkexcept,").  The 
two  backup  systems  have  different  interfaces  and  do  not  work  in  a  compatible  manner. 

3. 9.6.7 £  Related  standards.  The  following  standards  are  related  to  backup  and  restore  or 
backup  and  restore  standards. 

a.  ISO/IEC  9595:  CMIS. 

b.  ISO/IEC  9596:  CMDP. 

c.  ISO/IEC  DIS  1 1578.2:  RPC. 

d.  Network  Management  Forum:  OMNIPoint  1. 

e.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

f.  Internet  RFC  1 157:  Simple  Network  Management  Protocol. 

g.  Internet  RFC  1 158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

3.9.6.7.6  Recommendations.  ISO/IEC  9945-1  and  ISO/IEC  9945-2  archiving  services  are 
recommended.  The  operating  system  standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC 
9945-1:1990,  IEEE  1003. 1  b:  1993,  IEEE  1003.  lc:  1995,  and  IEEE  1003. 1  i:  1 995)  arc  all 
incorporated  in  the  new  ISO/IEC  9945-1:1996.  Federal  Information  Processing  Standard  (FIPS) 
151-2  should  also  be  consulted.  It  adopted  ISO  9945- 1:1990  and  is  still  applicable  to  the  1996 
version.  "Pax"  was  commissioned  for  POSIX.2  because  "tar"  and  "cpio"  were  considered 
inadequate.  "Pax"  is  similar  to  "tar"  and  "cpio."  The  "tar"  and  "cpio"  formats  are  expected  to  be 
retired  from  a  future  version  of  POSIX.  1  in  favor  of  the  newer  "ustar"  format. 
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3.9.6JJ  Hardware  error  and  event  conditions.  (This  BSA  appears  in  both  part  8  and  part  9.) 
An  event  is  an  unsolicited  communication  from  a  hardware  device  to  a  computer  operating 
system,  application,  or  driver.  Events  are  generally  attention-getting  messages,  allowing  a 
process  to  know  when  a  task  is  complete  or  when  an  external  event  occurs.  Error  conditions 
(e.g.,  system  failures,  unauthorized  access  attempts,  or  strange  glitches)  must  be  detected  and 
reported  so  corrective  action  can  be  taken  to  minimize  system  or  network  problems.  (See  the 
BSA  on  error  and  event  logging  for  more  information  on  tracking  errors.) 

Offline  diagnosis  of  events  which  have  been  written  in  encoded  form  to  the  system  log  is  termed 
event  classification.  Encoded  events  which  are  written  to  the  system  log  for  later  analysis  form 
the  raw  material  for  algorithms  designed  to  diagnose  and  passivate  faults,  that  is  to  prevent  them 
from  being  reactivated.  Offline  classification  of  errors  or  events  which  are  indicative  of  the 
potential  failure  of  a  component  can  be  conducted  only  when  the  required  information  has  been 
saved.  Algorithms  designed  to  improve  system  maintenance  and  to  shorten  the  duration  of 
outages  generally  scan  the  system  event  log  for  patterns  of  event  types.  Such  algorithms  can  be 
used  to  predict  imminent  failure  of  software  or  hardware  components.  This  analysis  of  logged 
events  could  also  be  processed  in  parallel  while  the  main  system  continues  to  perform. 

Services  for  the  detection  of  events  come  in  two  basic  forms:  active  and  passive.  Events  come  in 
two  types,  those  which  are  anomalous  and  those  which  are  not.  Anomalous  events  may  be 
classified  into  two  categories:  errors,  and  events  which  are  indicative  of  a  fault  which  is  not  yet 
producing  errors,  but  is  the  cause  of  some  degradation  in  system  performance.  P1003. 1  h  is 
already  addressing  passive  errors  in  their  draft  standard. 

3.9.6.8.1  Standards.  Table  3.9-33  presents  standards  for  hardware  error  and  event  conditions. 


TABLE  3.9-33  Hardware  error  and  event  conditions  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Portable  Operating  Sy item  Interface  (PQSIX)  Put  1 : 
System  API  (Replaces  ISO  9945*  1 : 1990  and  incorporate! 
IEEE  1003.1b.  1003.1c.  and  1003.1i) 

9945-1:1996 

Mandated  | 

(Approved)  | 

CPC 

X/Ope«> 

Single  Unix  Specification  (Spec.  1 170),  System  Interface 
Definition! ,  Issue  4.  Version  2  (part  of  XP04) 

C434  (9/94) 

Emerging  1 

(Approved)  1 

CPC 

X/Open 

Single  Unix  Specification  (Spec.  1 170),  System  Interface! 
and  Headen,  Issue  4.  Venion  2,  (Part  of  XPG4) 

C435  (9/94) 

Emerging  | 

(Approved)  jj 

NPC 

IEEE 

Portable  Operating  System  Interface  (POSDO  -  Part  1 : 
System  Application  Program  interface  (API)  Amendment 

1 :  Realtime  Extension  (C  language) 

1003.  lb:  1993 

Informational  J 
(Approved)  | 

NPC 

IEEE 

POSIX  Part  1 :  System  Application  Program  Interface 
(API)  •  Amend;  Technical  Corrigenda  to  Real  Time 
Extension  |C  Language) 

I003.1i:1995 

Informational  | 
(Approved) 

GPC 

NIST 

Portable  Operating  System  Interface  (POSIX)  •  System 
Application  Program  Interface/  C  Language  (adopts 
ISO/IEC  9945-1  1990) 

FIPS  PUB  151- 
2:1993 

Informational  | 
(Approved)  | 

A'-pfi 

HotKS 

m 

hoSTS 

flnwtint 

(Foomiw*) 

April  7,  1997 


3.9-74 


Version  3.1 


Information  Technology  Standards  Guidance 


System  Management  Services 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

HHl! 
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3.9.6.8.2  Alternative  specifications.  The  OSFs  OSF/I  (product  implementation)  is  also 
available. 

3.9.6.8.3  Standards  deficiencies.  POSIX.  1  has  limited  event  management  capabilities. 

3.9.6.8.4  Portability  caveats.  Symbolic  error  numbers  are  a  set  of  names  defined  for  error 
numbers  set  by  the  "exec"  functions  to  indicate  the  nature  of  an  error  condition  that  has  occurred. 
Symbolic  error  numbers  have  been  around  for  a  long  time  and  are  reasonably  stable.  However, 
many  implementations,  especially  the  newer  ones,  use  symbolic  error  numbers  that  are  different 
from  one  another.  Applications  using  such  new,  different  symbolic  error  numbers  are  not  portable 
except  to  implementations  using  the  same  error  number  set 

POSIX,  X/Open,  and  SVID  support  many  of  the  same  symbolic  error  numbers,  with  some 
exceptions.  For  example,  POSIX  does  not  support  the  error  symbols  "EIDRM”  (indicating  an 
identifier  has  been  removed  from  the  system),  "ENOMSG"  (required  message  not  in  the  message 
queue),  and  "ETXTBSY"  (attempt  to  overwrite  active  procedure),  even  though  X/Open,  and 
SVID  support  them.  Other  differences  in  symbolic  error  numbers  occur  in  the  following  error 
symbols:  "EBADMSG,"  "ENOSR,"  "ENOSTR,"  "EPROTO,"  "ERESTART,"  and  "ET1ME." 

Symbolic  error  numbers  provide  portability  only  if  programmers  and  vendors  implement  programs 
using  them.  Implementations  using  numeric  numbers  instead  of  symbolic  error  names  and 
numbers  are  not  portable. 

POSIX,  X/Open,  and  SVID  allow  additional  implementation-defined  symbolic  error  names  to  be 
created.  Such  implementation-defined  symbolic  error  numbers  may  be  a  necessity  for  a  particular 
application.  These  values  are  usually  returned  by  extended  functionality,  not  defined  by  POSIX.  1. 
The  SVID,  for  example,  defines  the  symbolic  errors  "EBADMSG",  "ENOSR",  and  "ENOSTR" 
which  are  returned  by  the  kemal  "STREAMS"  subsystem.  These  new  symbolic  error  numbers 
should  be  portable  among  all  systems  which  provide  the  underlying  functionality.  The  longest  of 
the  symbolic  error  number  names  is  "ENAMETOOLONG." 

X/Open.'s  Single  Unix  Specification  (Spec  1 170)  has  aligned  XPG4  with  POSIX  in  the  areas 
where  they  overlap.  Thus  any  XPG4  or  Single  Unix  conforming  system  is  guaranteed  to  respond 
with  the  same  symbolic  error  value  although,  as  discussed  above,  the  actual  error  number  may 
vary. 
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3.9.6A5  Related  standards.  The  following  standards  are  related  to  hardware  error  conditions: 

a.  IEEE  1003.2:1992:  POSIX  -  Shell  and  Utility  Application  Interface. 

b.  IEEE  R1003.5: 1992:  Ada  Language  Binding  for  POSIX  (under  revision). 

c.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

d.  IEEE  PI 387. 1 :  POSIX  System  Administration  -  Part  1 :  Overview. 

e.  IEEE  1387.2: 1995:  POSIX  System  Administration  -  Part  2:  Software. 

f.  IEEE  P1387.3:  POSIX  System  Administration  -  Part  3:  User  and  Group 
Administration. 

g.  IEEE  P1003. lg:  Protocol  Independent  Interfaces. 

h.  IEEE  1224.2:1993:  Directory  Services  API  -  Language  Independent. 

i.  IEEE  1224.1: 1993:  X.400  Based  Electronic  Messaging  API. 

j.  IEEE  P1238.1:  OSI  Applications  Program  Interface  -  FTAM. 

k.  IEEE  P1351:  OSI  Application  Interfaces  -  ACSE. 

3.9.6.8.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/1EC  9945-1:1990,  IEEE  1003. 1  b:  1 993, 
IEEE  1003.1c:  1995,  and  IEEE  1003. 1  i:  1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  Federal  Information  Processing  Standard  (FIPS)  151-2  should  also  be  consulted.  It 
adopted  ISO  9945- 1 : 1 990  and  is  still  applicable  to  the  1 996  version.  IEEE  1 003. 1  b  added 
asynchronous  event  notification  to  the  original  IEEE  1003. 1 .  FIPS  151-2  specifies  the  read/write 
return  options.  SUS  supports  additional  error  symbols. 

To  get  the  better  event  management  capabilities  needed  for  networking,  communications, 
transaction  processing,  and  real  time  applications,  explicitly  specify  the  IEEE  1003.1b  standard's 
real  time  signals  option  for  asynchronous  event  notification.  For  U.S.  Federal  Government 
procurements,  the  NIST  Application  Pojfability  Profile  (APP)  and  FIPS  151-2  have  some  special 
file  and  directory  requirements: 

a.  The  APP  and  FIPS  151-2  require  support  for  the  error  message 
"ENAMETOOLONG"  for  the  open  command. 

b.  The  APP  and  FIPS  151-2  require  read()  calls  and  write()  calls  that  are  interrupted 
by  a  signal  after  they  have  successfully  read  or  written  data  shall  return  the  number 
of  bytes  the  system  has  read.  POSIX  allows  the  return  of  either  the  number  of 
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bytes  read  or  written  or  a  return  of  -1  with  "ermo"  set  to  [EINTR]  after  a 
successful  read  or  write. 

To  get  greater  functionality  than  POSIX  provides,  establish  the  error  management  interfaces 
provided  by  X/Open  as  an  internal  standard.  The  problem  is  that  in  implementations  compliant 
with  POSIX,  many  specific  system  calls  have  differences  in  their  error  messages  and  exception 
management  handling.  These  system  call  commands  must  be  analyzed  to  see  which  enor 
messages  to  specify  for  certain  critical  commands,  as  the  NIST  did  in  developing  FIPS  151-1.  A 
second  problem  occurs  because  X/Open,  the  SVID,  and  OSF  specify  more  functionalities  than 
POSIX.  Even  whr  these  functionalities  are  the  same,  X/Open's,  the  SVID's,  and  OSF/l's  error 
messages  are  often  different  In  general,  X/Open's  error  messages  for  specific  system  calls  tend  to 
be  the  same,  but  they  differ  from  OSF/l's,  which  is  the  same  as  Berkeley  UNIX's. 
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3.9.6.9  Event  management.  Event  management  and  notification  services  allow  system  managers 
and  system  administrators  to  be  informed  that  a  predefined  system  or  network  event  of  interest 
(e.g.,  additional  resources  needed)  has  occurred,  so  that  the  event  may  be  managed  in  a 
predefined  way  that  prevents  network  or  system  problems.  Event  management  is  related  closely 
to  fault  and  performance  management,  in  that  each  of  ihese  services  could  make  use  of  event 
management  to  log,  track,  and  provide  alerts  based  on  relevant  events. 

3.9.6.9.1  Standards.  Table  3.9-34  presents  standards  for  event  management. 


TABLE  3.9-34  Event  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  I  (Adopts  ISO  Profile  SeU  1 1 183-X,  12059- 
X,  end  12060-X,  include!  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

GPC 

NIST 

Si-bte  Implementation  Agreement!  for  Open  Syitem 
Environment!,  Ver.  8,  Ed.  1 

Special  **ub.  500- 
224:12/94 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Syitem*  Management,  Part  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

Portable  Operating  Syitem  Interface  (POSDQ  Part  1 : 
Syitem  API  (Replace*  ISO  9945- 1:1990  and  incorporate! 
IEEE  1003.  lb,  1003.1c.  and  1003.1i) 

9945-1:1.996 

Informational 

(Approved) 

NPC 

IEEE 

Portable  Operating  Syitem  Interface  (POSDC)  -  Part  1 : 
System  Application  Program  Interface  (API)  Amendment 

1 :  Realtime  Extemion  (C  language) 

1003.  lb:  1993 

Informational  l 
(Approved)  J 

3.9.6.9.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  Banyon  Systems'  Network  Event  Logger  (from  Wang  Laboratories)  on  which 
OSF's  Event  Notification  Component  is  based. 

b.  Banyon  Systems'  PC  library  for  the  Network  Event  Logger,  which  filters  and  logs 
PC  events  locally  and  sends  them  to  a  Network  E\  :  Logger  server  on  a  host 
system  for  further  processing.  The  OSF  DME’s  PC  Error  Logging  Component  is 
based  on  this  Banyon  Systems'  PC  library. 

3.9.6.9.3  Standards  deficiencies.  None  of  the  event  notification  components  in  any  of  the 
consortia  management  systems  are  compatible  with  the  IEEE  P1003. 1  b  specifications  for  event 
notification.  OSF  DME  event  management  is  intended  to  be  used  as  the  basis  for  commercial 
management  systems,  but  is  not  currently  supported  by  any  products. 

3.9.6.9.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 
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3.9. 6. 9.5  Related  standards.  The  following  standards  are  related  to  event  management  and 
notification  standards: 

a.  ISO/IEC  DIS  1 1578.2:  RPC  (Replaces  DIS  1 1578  PT  1  Thru  PT  4.) 

b.  NIST  APP  -  Special  Pub.  500-230:  1995. 

c.  OSF:  Distributed  Computing  Environment  (DCE)  Remote  Procedure  Call 
Component. 

d.  USL/Sun  Microsystems:  Open  Network  Computing  (ONC)  Remote  Procedure 
Call  (RPC)  Component 

e.  NIST  FIPS  179-1:1995:  Government  Network  Management  Profile  (GNMP). 

f.  ISO/IEC  9596-1:1991:  OSI CMIP,  Part  1:  Specification. 

g.  IAB:  RFC  1157:  SNMP. 

3.9.6.9.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program  defines 
a  collection  of  specifications  for  the  management  of  network  and  distributed  systems  using  open 
standards  and  specifications. 
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3.9.6.10  Process  checkpoint  and  restart  (This  BSA  appears  both  in  part  8  and  part  9.) 
Checkpoint  and  restart  is  a  method  of  recovering  from  a  system  failure.  A  checkpoint  is  a  copy  of 
the  computer's  memory  saved  periodically  on  disk  along  with  the  current  register  settings  (e.g., 
the  last  instruction  executed).  In  the  event  of  any  failure,  the  last  checkpoint  serves  as  a  recovery 
point.  When  the  problem  has  been  fixed,  the  restart  program  copies  the  last  checkpoint  into 
memory,  resets  all  the  hardware  registers,  and  starts  the  computer  from  that  point.  Any 
transactions  in  memory  after  the  last  checkpoint  was  taken  until  the  failure  occurred  will  be  lost. 
Checkpoint  restart  is  helpful  in  any  system  running  long  jobs  and  requiring  more  time  than  can  be 
expected  between  system  down-times,  and  in  any  job  that  would  be  inconvenient  to  start  over  in 
the  event  of  a  system  failure. 

3.9.6.10.1  Standards.  Table  3.9-35  presents  standards  for  process  checkpoint  and  restart. 


TABLE  3.9-35  Process  checkpoint  and  restart  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

(IVnxtra) 

3.9.6.10.2  Alternative  specifications.  The  only  other  specifications  available  are  proprietary. 

3.9.6.10.3  Standards  deficiencies.  P1003.  la  does  not  specify  how  files  and  directories  are 
identified  in  the  checkpoint  file. 

3.9.6.10.4  Portability  caveats.  One  checkpoint  restart  implementation  provides  a  value  of 
"RESTART_FORCE"  to  restart  a  checkpoint  file  or  directory,  whether  or  not  it  could  be 
restarted  rationally.  This  behavior  cannot  be  used  in  a  portable  way,  since  no  predictable  meaning 
exists  for  restarting  a  process  that  was  in  a  condition  that  could  not  be  checkpointed. 

3.9.6.10.5  Related  standards.  ISO  IS  9804/9805:  CCR  is  related  to  process  checkpoint  and 
restart. 

3.9.6.10.6  Recommendations.  Too  many  unresolved  issues  are  in  the  checkpoint  restart 
specification  in  the  P1003.  lm  draft  standard  to  specify  the  emerging  checkpoint  restart 
specification.  Issues  range  from  the  error  codes  to  how  much  of  the  process  state  to  specify 
explicitly. 

Checkpoint/restart,  originally  in  P 1003.  la  system  services  as  a  separate  API  is  now  a  separate 
IEEE  project  work  item  under  PI 003.  lm.  This  work  was  started  by  the  Super  Computer  and 
Batch  processing  systems  working  groups  in  conjunction  with  the  PI 003.  la  working  groups  to 
provide  mechanisms  to  suspend  a  long  executing  job  and/or  provide  checkpoints  along  the  way  so 
it  could  be  restarted  if  something  happened  during  execution. 
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3.9.6.11  Error  and  event  logging.  (This  BSA  appears  both  in  part  8  and  part  9.)  Error  logging 
is  the  automatic  logging  of  errors  and  events  to  a  log  (special  file)  to  avoid  system  or  network 
faults  (by  detecting  that  the  operation  of  a  component  is  approaching  the  edge  of  its  operational 
range)  and  to  provide  a  historical  record  that  can  be  studied  to  diagnose  faults  after  their 
occurrence  and  perhaps  prevent  their  happening  in  the  future. 

On  the  detection  of  events  of  interest,  the  operating  system  may  automatically  write  the  encoded 
event  to  the  system  log  and/or  may  notify  a  process  of  the  occurrence.  This  is  certainly  the  case 
when  an  error  with  a  high  severity  level  is  detected.  Logging  or  notification  may  occur  at  any  time 
in  the  operation  of  a  system.  They  may  occur  when  an  application  or  the  operating  system  has 
detected  an  error,  when  an  event  has  been  generated  during  event  classification  (especially  if  the 
event  is  indicative  of  imminent  failure  of  a  component),  or  when  an  event  is  severe  and  requires 
the  immediate  attention  of  a  process  and  when  a  corrective  action  is  taken,  such  as  when  a 
processor(hardware)  or  process(software)  is  being  registered  for  service. 

3.9.6.11.1  Standard.  Table  3.9-36  presents  standards  for  error  and  event  logging. 


TABLE  3.9-36  Error  and  event  logging  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status  | 
DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  I  (AdopU  ISO  Profile  Sets  1 1 183-X.  12059- 
X,  and  1206O.X,  include*  ISQ/IEC  10164-X) 

OMNIPoint  1:1993 

Adopted 

(Approved) 

IPC 

ISO/IEC 

OSI  Syttem*  Management,  Part  4:  Alarm  Repotting 
Function 

10164-4:1992 

Informational 

(Approved) 

[PC 

ISO/tEC 

OSI  System*  Management,  Part  5:  Event  Report 
Management  Function 

10164-5:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  System*  Management,  Part  6:  Log  Control  Function 

10164-6:1993 

Informational 

(Approved) 

CPC 

XA)pen 

Single  Uni*  Specification  (Spec.  1170),  System  Interface 
Definition* ,  Issue  4,  Version  2  (part  of  XPG4) 

C434  (9/94) 

Emerging 

(Approved) 

CPC 

X/Open 

Single  Uni*  Specification  (Spec.  1 170),  System  Interfaces 
and  Headers,  Issue  4,  Version  2,  (Part  of  XPG4) 

Emerging 

(Approved) 
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3.9.6.11.2  Alternative  specification.  The  following  specifications  are  also  available: 

a.  Banyon  Systems'  Network  Event  Logger  (NeL)  (from  Wang  Laboratories)  on 
which  OSF's  Event  Notification  Component  is  based. 

b.  Banyon  Systems'  PC  library  for  the  Network  Event  Logger  (NeL),  which  filters 
and  logs  PC  events  locally  and  sends  them  to  a  Network  Event  Logger  server  on  a 
host  system  for  further  processing. 
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3.9.6.11.3  Standard  deficiencies.  No  Ada  bindings  are  available  for  any  of  the  consortium's 
system  management  Error  Logging  Components. 

3.9.6.11.4  Portability  caveats.  Portability  problems  related  to  the  existing  standards  are 
unknown 

3.9.6.115  Related  standards.  The  following  standards  are  related  to  error  logging  standards: 

a.  ISO/IEC  DIS  1 1578.2:  OSI  -  RPC  (Replaces  DIS  1 1578  PT  1  Thru  PT  4). 

b.  NIST  APP  -  Special  Pub.  550-230: 1995. 

c.  OSF:  DCE  RPC  Component. 

d.  USL/Sun  Microsystems:  Open  Network  Computing  (ONC)  RPC  Component. 

3.9.6.11.6  Recommendations.  OMNIPoint  1  is  recommended.  The  OMNIPoint  program 
defines  a  collection  of  specifications  for  the  management  of  network  and  distributed  systems 
using  open  standards  and  specifications. 
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3.9.7  Security  monitoring.  Security  monitoring  provides  management  services  which  contribute 
to  the  protection  of  open  systems  information  resources  in  accordance  with  applicable  security 
policies. 

3.9.7.1  System  development.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Development 
of  secure  systems  requires  that  security  engineering  be  a  key  discipline  in  conjunction  with  other 
system,  software,  and  hardware  engineering  activities. 

3.9.7.1.1  Standard.  Table  3.9-37  presents  standards  for  system  development 


TABLE  3.9-37  System  development  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trurted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  Interpretation 

NCSC-TG-005, 
Version  1:  1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-02I, 
Version  1:  1991 

Mandated 

(Approved) 

CPC 

OSF 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

DOD 

FORTE2ZA  Cryptologic  Programmers'  Guide 

MD40000501- 

1.52:  1996 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Application  Implementors'  Guide 

MD4002101-1.52: 

1996 

Mandated 

(Approved) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Informational 

(Approved) 

IPC 

ISO/IEC 

Software  Life  Cycle  Processes 

12207:1995 

Informational 

(Approved) 

NPC 

HA 

Trial  Use  Standard  -  Standard  for  Information  Technology 
-  Software  Life-Cycle  Processes  -  Software  Development  - 
Acquirer-Supplier  Agreement 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(same  as  CCITT  X.S00: 1991) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Security  of  Computer  Applications 

FIPS  PUB  83:1980 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory.  Abstract  Service  Definition:  (same  as 
ITU-T X.5U  (1993)) 

9594-3:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory:  Procedures  for  Distributed 
Operations: (same  as  ITU-T  X.5 19(1993)) 

9594-4:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

hb^shh 

9594-8:1993  (or 
1994) 

Informational 

(Approved) 

CPC 

X/Opcn 

Generic  Security  Service  API  (GSS-  API)  Base 

C44I  (12/95) 

Informational 

(Approved) 

isc 
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Sponsor 


Standard 

Type 


Standard 


Standard 

Reference 


Status 

DoD 


_ 


3.9.7.1.2  Alternative  specification.  There  are  no  alternative  specifications. 

3.9.7.13  Standard  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.1.4  Portability  caveats.  If  FORTF.ZZA  services  are  used,  the  following  guidelines  should 
be  consulted: 


a.  MD4002101-1.52, 3/5/96,  FORTEZZA  Application  Implementors'  Guide 

b.  MD40050 1- 1 .52,  1/30/96,  FORTEZZA  Cryptologic  Programmers’  Guide, 

Revision  1.52 

3.9.7.1.S  Related  standards.  DOD  Directive  5200.28  "Security  Requirements  for  Automated 
Information  Systems  (AISs),"  provides  the  DOD-wide  program  for  AIS  security.  It  provides 
mandatory,  minimum  AIS  security  requirements  for  systems  processing  classified,  sensitive  but 
unclassified,  and  unclassified  information.  For  intelligence  systems,  Director,  Central  Intelligence 
Directive  (DCID)  1/16,  "Security  Policy  for  Uniform  Protection  of  Intelligence  Processed  in 
Automated  Information  Systems  and  Networks,"  and  "Security  Manual  for  Uniform  Protection  of 
Intelligence  Information  Processed  in  Automated  Information  Systems  and  Networks,"  should  be 
used  in  conjunction  with  DOD  5200.28-STD.  The  following  guidelines  also  are  for  use  with 
DOD  5200.28-STD: 

a.  NCSC-TG-006,  Version  1,  28  March  1988,  A  Guide  to  Understanding 
Configuration  Management  in  Trusted  Systems 

b.  NCSC-TG-007,  Veision  1,  2  October  1988,  A  Guide  to  Understanding  Design 
Documentation  in  Trusted  Systems 

c.  NCSC-TG-008,  Version  1,  15  December  1988,  A  Guide  to  Understanding  Trusted 
Distribution  in  Trusted  Systems 
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d.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in 
Trusted  Systems 

e.  NCSC-TG-023,  Version  1,  July  1993,  A  Guide  to  Understanding  Security  Testing 
and  Test  Documentation  in  Trusted  Systems 

3.9.7.1.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 

MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  MIL-STD-498  contains  requirements  for  security  and  privacy  for  software 
development  and  documentation.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640) 
is  based  on  MIL-STD-498  and  was  issued  30  September  1995  as  i.  joint  EIA/IEEE  trial  use 
standard.  It  is  anticipated  that  J-STD-016  will  be  upgraded  fiom  trial  use  to  full  use  and  issued  as 
an  ANSI  standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of 
ISO/IEC  12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a 
base  standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISO/IEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207.1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207 .2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  management,  and  acquirer-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  September  1997.  The  long  range  goal  is 
migration  to  full  use  of  IEEE/EIA  12207US;  however,  EIA/IEEE  J-STD-016  can  be  used  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  approval,  until  organizational  processes 
for  IEEE/EIA  12207US  are  in  place. 

If  FORTEZZA  services  are  used,  the  following  two  guidelines  should  be  consulted: 

a.  MD4002 101-1.52, 3/5/96,  FORTEZZA  Application  Implementors'  Guide 

b.  MD4000502- 1 .52,  1/30/96,  FORTEZZA  Cryptologic  Programmers' Guide, 
Revision  1.52 
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3.9.7.2  Security  management.  (This  BSA  appears  in  part  7,  part  8,  part  9,  and  part  10.) 

Security  management  is  a  particular  instance  of  information  system  management  Security 
management  provides  supporting  services  that  contribute  to  the  protection  of  information  and 
resources  in  open  systems  in  accordance  with  information  domain  and  information  security 
policies.  The  basic  elements  that  must  be  managed  are  users,  security  policies,  information, 
information  processing  systems  that  support  one  or  more  security  policies,  and  the  security 
functions  that  support  the  security  mechanisms  (automated,  physical,  personnel,  or  procedural) 
used  to  implement  security  services.  For  each  of  these  elements,  the  managed  objects  that 
constitute  them  must  be  identified  and  maintained.  For  example,  users  must  be  known  and 
registered,  security  policies  must  be  represented  and  maintained  and  information  objects  must  be 
identified  and  maintained.  Security  policies,  security  services  and  security  mechanisms  are  the  first 
classes  of  managed  objects. 

3.9.7.2.1  Standards.  Table  3.9-  38  presents  standards  for  security  management 


TABLE  3.9-38  Security  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Networt  Interpretation 

NCSC-TG-005, 
Version  1: 1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-021. 
Version  1: 1991 

Mandated 

(Approved) 

CPC 

OSP 

DCE  |.l  Security 
Servj-ei:  1994 

Mandated 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
ref:  ISO  9594-4) 

X.518:  1993 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Services  (CM1S) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Open  Systems  Interconnection  - 
Common  Management  Information  Protocol  (CMIP)  -  Past 

1:  Specification  (Includes  amendment  I  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

CPC 

NMF 

OMNIPoinl  l  (Adopts  ISO  Profile  Sets  1 1 183-X,  12059- 
X.  and  12060-X.  includes  ISO/IEC  10164-X) 

OMNIPoml  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  7:  Security  Alarm 
Reporting  Function  (same  as  ITU-T  X.736) 

10164-7:1992 

informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  8:  Security  Audit  Trail 
Function  (same  as  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  9:  Objects  and  Attributes 

for  Access  Control 

10164-9:1995 

Inform  altonal 
(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(same  as  CC ITT  X.800: 1991 ) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Government  Networic  Management  Profile  f(JNMP) 
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Standard 

Type 


Sponsor 


Standard 


Standard 

Reference 


Status 

DoD 


-m1.  .■■jarary  r"*r  .~.rrr~ r 

1  "  <rw»T“ 


3.9.7.2.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.1.23  Standards  deficiencies.  Deficiencies  exist  in  standardization  of  security  policy  rule 
representation;  key  management,  including  generation,  distribution,  and  accounting;  audit 
information  formats;  exchange  of  security  management  information;  and  remote  security 
management 

The  DGSA  principle  of  decision  and  enforcement  separation  requires  that  the  functions 
determining  how  to  enforce  a  security  policy  and  the  actual  enforcement  of  the  policy  be 
implemented  independently.  That  is,  the  enforcement  mechanisms  do  not  need  any  knowledge  of 
security  policy.  Standards  are  needed  for  object  class  definitions  for  classes  of  managed  objects 
and  for  methods  of  representing  security  policy. 

The  DGSA  calls  for  a  separation  mechanism,  such  as  separation  kernel,  to  mediate  all  calls  to 
security  critical  functions  to  ensure  that  strict  isolation  is  maintained.  Standardization  of  object 
class  definitions  for  management  of  critical  functions  used  within  the  separation  kernel  is  needed. 

The  present  ISO/IEC  10164-7  "Security  Alarm  Reporting  Function,"  and  10164-8,  "Security 
Audit  Trail  Function,"  standards  were  designed  with  network  security  in  mind.  Little  work  has 
been  done,  either  in  standards  groups  or  in  products,  on  how  to  use  these  standards  for  general 
system  management  (e.g,,  computer  systems  and  software). 

FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  The  present  GNMP  specifications  require  ISO 
CMIS/CMIP  to  communicate  management  information  and  ISO  OS1  networking  protocols. 
Plans  are  for  the  GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with 
SNMP.  One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 
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No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 

The  IEEE  POSIX  Security  Working  Group  (formerly  P1003.5)  is  defining  security  extensions  to 
the  base  POSIX  interface  standard  (ISO  9945-1),  to  include  support  for  audit,  privilege, 
discretionary  and  mandatory  access  control,  and  information  labels.  These  have  been 
redesignated  IEEE  P1003.  le  and  IEEE  P  1003.2c.  The  draft  standards  are  still  incomplete,  and 
the  specifications  may  change. 

The  POSIX/UNIX  permission  bits  are  inadequate  for  fine-grained  control  over  exactly  which 
users  can  perform  specified  actions  to  particular  files. 

In  the  IETF,  efforts  to  develop  an  acceptable  security  standard  for  SNMPv2  have  been  on  hold 
since  September  1995  when  the  IETF  SNMP  Working  Group  failed  to  agree  on  the  proposals 
submitted.  Since  then,  two  sets  of  proposals  for  providing  SNMPv2  security  have  emerged.  The 
first  set  of  proposed  specifications,  the  User-based  Security  Model  (USEC),  also  referred  to  as 
SNMPv2u,  consists  of  two  documents:  RFC  1909,  "An  Administrative  Infrastructure  for 
SNMPv2"  and  RFC  1910,  "The  User-based  Security  Model  for  SNMPv2."  Both  RFCs  were 
issued  28  February  1996  and  are  classified  by  the  IETF  as  experimental  RFCs.  The  other 
proposal  is  known  as  SNMPv2*,  which  its  proponents  claim  is  heavily  based  on  USEC.  Neither 
USEC  nor  SNMPv2*  has  been  approved  for  a  standards  track  by  IETF. 

3.9.7.2.4  Portability  caveats.  The  structure  of  certain  traditional  UNIX  directories,  such  as  the 
familiar  "/tmp,"  "/usr/spool,"  and  "/usr/spool/mair  directories  will  have  to  change  to 
accommodate  the  P1003.  le  and  P1003.2C  security  standards.  This  is  because  these  are 
directories  to  which  all  users  have  access  and  to  which  many  programs  write.  A  change  in  the 
way  programs  write  to  directories  has  the  potential  for  causing  software  portability  and  systems 
administrator  portability  problems. 

The  traditional  UNIX  permission  bits  that  have  been  carried  into  POSIX  are  inadequate  for 
defining  exactly  which  user  can  perform  specific  actions  on  specific  files.  Eliminating  the 
permission  bits  in  favor  of  Access  Control  Lists  could  make  the  secure  POSIX  systems 
incompatible  with  non-POSIX  compliant  systems  and  many  applications. 

OSF  DCE  version  1.1's  authentication  service  is  based  on  Kerberos  Version  5  (RFC  1510),  but  is 
not  tatally  compatible  with  RFC  1510.  DCE  1.2.2  adds  testing  and  official  support  for  Kerberos 
Version  5. 

3.9.7.2.5  Related  standards.  1SO/1EC  9945-1  as  profiled  by  FIPS  PUB  151-2  is  related  to  IEEE 
P1003.1e  and  IEEE  P1003.2c. 

3.9.7.2.6  Recommendations.  The  mandated  standards  are  recommended. 

All  IEEE  P1003.1e  and  IEEE  P1003.2c  security  systems  should  incorporate  Access  Control  Lists 
as  an  optional  feature  in  addition  to  permission  bits  (not  "in  place  of"  permission  bits).  The 
incompatibilities  between  the  two  access  control  methods  (permission  bits  and  access  control 
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lists)  are  not  resolvable.  The  best  method  for  resolving  the  overall  problems  seem  to  be 
incorporation  Access  Control  Lists  as  an  optional  feature  on  top  of  permission  bits.  The 
permission  bits  would  represent  the  lowest  common  denominator  of  security,  showing  the 
maximum  amount  of  openness  possible  in  a  system.  Organizations  needing  only  the  lowest  level 
of  security  could  continue  to  use  the  familiar  permission  bits  and  associated  "chmod"  command. 
Use  of  access  control  lists  will  require  a  change  in  security  policy  such  that  access  is  granted  if 
and  only  if  permission  is  granted  ai.u  access  control  permits  it 
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3.9.7 3  Security  risk  management.  (This  BSA  appears  in  part  2,  part  7,  part  9,  and  part  10.) 
Security  risk  management  supports  accreditation  through  a  risk  analysis  of  an  information  system 
and  its  operational  environment,  and  the  steps  taken  to  manage  the  risk  requirements. 

3.9.7.3.I  Standards.  Table  3.9-39  presents  standards  for  security  risk  management 


TABLE  3.9-39  Security  risk  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trutfed  Computer  System*  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guideline  for  the  Analysis  of  Local  Area  Network  Security 

FIPS  PUB 
191:1994 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Automated  Data  Processing  Risk  Analysis 

FIPS  PUB  65:1979 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Automatic  Data  Processing  Physical 
Security  and  Risk  Management 

FIPS  PUB  31:1974 

Informational 

(Approved) 

3.9.73.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.33  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  31  docs  not  include  information 
of  all  modem  security  concepts. 

3.9.73.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.73.5  Related  standards.  The  following  standards  are  related  to  the  TCSEC  standard: 

a.  CSC-STD-003-85  25  Jun-  1985,  Computer  Security  Requirements  -  Guidance  for 
Applying  the  Department  of  Defense  Trusted  Computer  Security  Evaluation 
Criteria  in  Specific  Environ' tents 

b.  CSC-STD-004-85, 25  June  1 985,  Technical  Rationale  Behind  CSC-STD-003-85: 
Computer  Security  Requirements  -  Guidance  for  Applying  the  Department  of 
Defense  Trusted  Computer  Security  Evt  ,  otion  Criteria  in  Specific  Environments 

3.9.73.6  Recommendations.  The  mandated  standard  is  recommended.  Office  of  Management 
and  Budget  (OMB)  Circular  A- 130,  "Management  of  Federal  Information  Resources,"  provides 
guidance  on  effective  security  risk  management  of  federal  information  systems.  NIST  Special 
Publication  800-12,  "An  Introduction  to  Computer  Security:  The  NIST  Handbook"  provides 
additional  guidance  on  risk  management.  DOD  Directive  5200.28  requires  a  risk  analysis  of  an 
information  system  be  conducted  in  its  operational  environment  to  support  accreditation  of  the 
information  system.  System  implementors  should  perform  the  risk  analysis  in  accordance  with 
CSC-STD-003-85  and  CSC-STD-004-85  to  determ  ine  the  appropriate  DOD-5200.28-STD  class. 
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3.9.7 .4  Security  audit  (This  BSA  appears  in  part  7,  part  9,  part  10,  and  part  1 1.)  Security 
auditing  is  a  review  or  examination  of  records  and  activities  to  test  controls,  ensure  compliance 
with  policies  and  procedures,  detect  breaches  in  security,  and  indicate  changes  in  operation 
(paraphrased  from  ISO  7498-2). 

3.9.7.4.I  Standards.  Table  3.9-40  presents  standards  for  security  audit 


TABLESj^O^Securitj^auditstandards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  EvsJustion  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profile  Sets  1 1 183-X,  12059- 
X,  and  12060-X,  includes  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSE  Sy stems  Management,  Part  8:  Security  Audit  Trail 
Ruction  (same  as  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

CPC 

X/Opw 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020:  1990 

Informational 

(Afftroved) 
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3.9.7.4.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.4.3  Standards  deficiencies.  ISO  Transaction  Processing  Security  work  (WDAMs  to  ISO 
10026-1,2,3)  is  in  the  early  stages.  Its  content  is  not  defined,  and  it  cannot  be  used  for 
procurement.  ISO  10164-8  does  not  define  a  security  audit,  or  explain  how  to  perform  one.  It 
does  not  define  implementation  aspects,  occasions  where  the  use  of  the  security  audit  trail 
function  is  appropriate,  or  the  services  necessary  for  the  establishment  and  normal  or  abnormal 
release  of  a  management  association. 

There  is  a  need  for  a  standard  for  programming  interfaces  to  support  development  of  portable 
tools  for  audit  trail  analysis  and  configuration. 

3.9.7.4.4  Portability  caveats.  Proposed  amendments  to  ISO  10026  have  ceased.  This  is  a  high 
portability  risk  area. 

3.9.7.4.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 
a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 
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b.  NCSC-TG-01 1,  Version  1, 1  August  1990,  Trusted  Network  Interpretation 
Environments  Quideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation 

c.  NCSC-TG-001,  Version  2,  June  1988,  A  Guide  to  Understanding  Audit  in  Trusted 
Systems 

3.9.7.4.6  Recommendations.  The  mandated  standard  is  recommended. 


April  7.  1997 


3.9-92 


Version  3.1 


Information  Technology  Standards  Ouidance 


System  Management  Services 


3.9.7 £  Security  alarm  reporting.  (This  BSA  appears  in  part  7,  part  9,  rart  10,  and  part  1 1 .) 
Security  alarm  reporting  is  the  capability  to  receive  notifications  of  securit  -related  events,  alerts 
of  any  misoperations  in  security  services  and  mechanisms,  alerts  of  attacks  on  system  security,  and 
information  as  to  the  perceived  severity  of  any  misoperation,  attack,  or  breach  of  security. 

3.9.7.5.1  Standards.  Table  3.9-41  presents  standards  for  security  alarm  reporting. 


TABLE  3.9-41  Security  alarm  reporting  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  t  (Adopt*  ISO  Profile  Sea  1 1 183-X,  12059- 
X,  and  12060-X,  includes  ISO/IFC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISQ/IEC 

OSI  Systems  Management,  Past  7:  Security  Alarm 
Repotting  Function  (same  as  ITU-T  X.736) 

101  -7:1992 

Informational 

(Approved) 

GPC 

_ 

NIST 

GovemmetU  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

Mg 
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3.9.75.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.5J  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  ISO  10164-7 
does  not  define  implementation  aspects,  specify  the  manner  in  which  management  is  accomplished 
by  the  user  of  the  Security  Alarm  Reporting  Function  (S  ARF),  define  interactions  that  result  in 
the  use  of  the  SARF,  or  specify  the  services  necessary  for  the  establishment  and  normal  and 
abnormal  release  of  a  management  association. 

3.9.7.5.4  Portability  caveats.  Portability  problems  with  file  existing  standards  are  unknown. 

3.9.7.5.5  Related  standards.  There  are  no  related  standards. 

3.9.7.5.6  Recommendations.  There  are  no  recommended  standards  foi  rity  alarm  reporting. 
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3.9.7.6  Personal  authentication.  (This  BSA  appears  in  part  2,  part  3,  part  9,  and  part  10.) 
Personal  authentication  supports  the  accountability  objective  of  being  able  to  trace  all  security 
relevant  events  to  individual  users.  In  addition  to  supporting  unique  identification,  standards  are 
provided  to  authenticate  the  claimed  identity. 

3.9.7.6.1  Standards.  Table  3.9-42  presents  standards  for  personal  authentication. 


TABLE  3.942  Personal  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

DCE  1.1  Security 
Service*:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Pa**  wo  id  Uuge 

FIPS  PUB  112: 
1985 

Mandated 

(Approved) 

CPC 

OSF 

Diitritwted  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  on  Evaluation  of  Technique*  for  Automated 
PenonaJ  Identification 

FIPS  PUB  48:1977 

Informational 

(Approved) 

IPC 

1SO/IEC 

Information  Technology  -  Open  Sy*tem*  Interconnection  • 
The  Directory:  Authentication  Framework  edition  2  (Same 
a*  ITU-T  X. 509: 1993) 

9594-8.2:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Uie  of  Advanced  Authentication  Technology 
Alternative* 

FIPS  PUB 
190:1994 

Informational 

(Approved) 
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3.9.7.6.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.6.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.6.4  Portability  caveats.  OSF  DCE  Version  1.1 's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 

3.9.7.6.5  Related  standards.  The  following  standards  are  related  to  personal  authentication 
standards  (particularly  TCSEC): 

a.  DOD  5200.28-STD,  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

b.  NCSC-TG-017,  Version  1,  "A  Guide  to  Understanding  Identification  and 
Authentication  in  Trusted  Systems 
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c.  CSC-STD-002-85,  "Password  Management  Guideline" 

d.  NCSC-WA-002-85,  "Personal  Computer  Security  Considerations" 

e.  ITU-T  X.509  (1993)  (same  as  ISO  9594-8),  The  Directory:  Authentication 
Framework 

3.9.7.6.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.9.7.7  Entity  authentication.  (This  BSA  appears  in  part  8,  part  9,  part  10,  and  part  1 1.)  Entity 
authentication  standards  address  data,  processes,  systems,  and  enterprises. 

3.9.7.7.1  Standards.  Table  3.9-43  presents  standards  for  entity  authentication. 


TABLE  3.9-43  Entity  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 

Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Computer  Date  Authentication 

FIPS  PUB 
113:1985 

Informational 

(Approved) 

GPC 

NIST 

Entity  Authentication  Using  Public  Key  Cryptography 

FIPS  PUB 
196:1996 

Emerging 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

Financial  Transactions  -  Retail  Banking  Security 
Requirements  for  Message  Authentication 

9807 

Informational 

(Approved) 

tPC 

ISO 

Entity  Authentication  Mechanisms  -  Part  1:  General  Model 

9798-1:1991 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  -  Part  3:  Entity 
Authentication  Using  a  Public  Key  Algorithm 

9798-3:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Use  of  Advanced  Authentication  Technology 
Alternatives 

FIPS  PUB 
190:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  2:  Mechanisms  Using 
Symmetric  Encipherment  Algorithms 

9798-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  4:  Mechanisms  Using  a 
Cryptographic  Check  Function 

9798-4:1995 

Informational 

(Approved) 

CPC 

X/Open 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020: 1990 

Informational 

(Approved) 
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3.9.7.7.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.7.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.7.4  Portability  caveats.  OSF  DCE  Version  1.1's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 
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3.9.7.7 £  Related  standards.  The  following  standards  are  related  to  entity  authentication: 

a.  DOD  NCSC-TG-017,  Version  1,  September  1991,  Guide  to  Understanding 
Identification  and  Authentication  in  Trusted  Systems. 

b.  FIPS  PUB  196, 1 1  October  1996. 

FIPS  PUB  196  becomes  effective  6  April  1996.  It  is  based  on  ISO/IEC  9798- 
3:1993  and  specifies  two  challenge-response  protocols  by  which  entities  in  a 
computer  system  may  authenticate  their  identities  to  one  another.  FIPS  PUB  196 
is  for  use  in  public  key  based  challenge-response  and  authentication  systems  at  the 
application  layer  within  computer  and  digital  telecommunications  systems. 

3.9.7.7.6  Recommendations.  The  mandated  standards  are  recommended. 


April  7,  1997 


3,9-97 


Version  3. 1 


Information  Technology  Standards  Guidance 


System  Management  Services 


3.9.7 .8  System  access  control.  (This  BS  A  appears  in  part  4,  part  9,  part  10,  and  part  1 1 .) 
System  access  control  standards  provide  high-level  guidance  on  access  control  frameworks  and 
implementation. 

3.9.7.8.1  Standards.  Table  3.9-44  presents  standards  for  system  access  control. 


TABLE  3.9-44  System  access  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

liillii 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  198S 

Mandated 

(Approved) 

CPC 

QSF 

Distributed  Computing  Environment  (DCE)  Security 
Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

CPC 

QSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

[PC 

ISO 

OSI  Basic  Reference  Model,  Pail  2:  Security  Architecture 
(same  as  CCITT  X.800:1991) 

7498-2: 1989 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Services  (CMIS) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

10164-9:1995 

Informational 

(Approved) 
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3.9.7.5.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.8.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.8.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.7.8.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 

a.  NCSC-TG-003,  Version  1,  September  1987,  A  Guide  to  Understanding 
Discretionary  Access  Control  in  Trusted  Systems 

b.  NCSC-TG-028,  Version  1,  May  1992,  Assessing  Controlled  Access  Protection 

c.  NCSC-TG-020-A,  August  1989,  Trusted  UNIX  Working  Group  (TRUSIX) 
Rationale  for  Selecting  Access  Control  List  Features  for  the  UNIX  System 

3.9.7.8.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.9.7.9  Network  access  control.  (This  BSA  appears  in  part  7,  part  9,  and  part  10.)  Access 
control  is  the  prevention  of  unauthorized  use  of  a  resource,  including  its  use  in  an  unauthorized 
manner. 

3.9.7.9.1  Standards.  Table  3.9-45  presents  standards  for  network  access  control. 


TABLE  3.9-45  Network  access  control  standards 


Standard  Sponsor 
Type 


Standard 

Reference 


GPC 

DOD 

GPC 

NSA 

NPC 

IPRP 

IPC 

ISO/IEC 

IPC 

ISO 

IPC 

ISO 

GPC 

NIST 

GPC 

NIST 

GPC 

NSA 

GPC 

NSA 

GPC 

NSA 

tSO/!Kt 

iliSilii 

AMHXn(D)-  Meauge  Handling  Syrian*  -  Menage 
Security  Protocol  (MSP)  Part*  1-5 


Data  Exchange  (SDH) 


3S]  Common  Management  Information  Services  (CM1S 
Definition,  with  Amendment  4:  Access  Control 


Tran* port  Layer  Security  Protocol  (TLSP)  (Includes 
Amentfcneot  I) 


Network  Layer  Security  Protocol  (NLSP) 


(SP4) 


Mesuge  Security  Protocol  (MSP) 


Menage  Security  Protocol  (MSP) 


MIL-STD-2045- 
18500: 1993 

Mandated 

(Approved) 

SDN. 301,  Reviiion 
1.5: 1989 

Mandated 

(Approved) 

802. 10b:  1992 

Legacy 

(Approved) 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

10736:1994 

Informational 

(Approved) 

11577:1994 

Informational 

(Approved) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

FIPS  PUB  83:1980 

Informational 

(Approved) 

SDN .401,  Rev. 
1.3:1989 

I.  jormalional 
(Approved) 

SDN.701,  v.  4.0, 
Rev.  A:  1997 

Emerging 

(Approved) 

SDN.701,  Rev.  3.0: 
1994 


3.9.7.9.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.9.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown.  FIPS  PUB 
179-1  supersedes  FIPS  PUB  1 79. 


April  7,  1997 


3.9-99 


Version  3. 1 


Information  Technology  Standards  Guidance 


System  Management  Services 


3.9.7.9.4  Portability  caveats.  Proposed  security  enhancements  to  FT  AM  (WDAM4  to  ISO 
8571)  has  ceased.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3.9.7.9.5  Related  standards.  NCSC-TG-005,  Version  1,  July  1987.  Trusted  Network 
Interpretation,  and  NCSC-TG-01 1,  Version  1,  August  1990,  Trusted  Networks  Interpretation 
Environments  Guideline  -  Guideline  for  Applying  the  Trusted  Network  Interpretation,  supports 
the  DOD  5200.28-STD. 

3.9.7.9.0  Recommendations.  The  mandated  standards  are  recommended. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5,  1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part.  Allied  requirements.  This  DOD 
Standardized  Profile  (DSP)  standard  will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP 
123  or  ACP  120,  Common  Security  Protocol,  when  the  revision  to  MSP  is  complete. 

SDN.701,  Rev.3.0,  is  used  with  DMS,  Phase  1.  It  is  for  use  with  legacy  systems  only. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  1 1577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

The  work  on  File  Transfer,  Access,  and  Management  (FTAM)  security  (WDAM4  to  ISO  8571) 
security  enhancements  has  been  suspended.  Procurements  requiring  access  control  for  FTAM  and 
transaction  processing  should  not  use  these  standards. 

IEEE  802. 10b  is  for  use  with  legacy  LANs  only. 
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3.9.7.10  Certification  and  accreditation.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 
Certification  and  accreditation  constitute  a  set  of  procedures  and  judgments  leading  to  a 
determination  of  the  suitability  of  the  system  to  operate  in  the  targeted  operational  environment 

Accreditation  is  the  official  management  authorization  to  operate  a  system.  The  accreditation 
normally  grants  approval  for  the  system  to  operate  (a)  in  a  particular  security  mode,  (b)  with  a 
prescribed  set  of  countermeasures  (administrative,  physical,  personnel,  communications  security, 
emissions,  and  computer  security  controls),  (c)  against  a  defined  threat  and  with  stated 
vulnerabilities  and  countermeasures,  (d)  within  a  given  operational  concept  and  environment,  (e) 
with  stated  interconnections  to  other  systems,  (0  at  an  acceptable  level  of  risk  for  which  the 
accrediting  authority  has  formally  assumed  responsibility,  and  (g)  for  a  specified  period  of  time. 
The  Designated  Approving  Authority(s)  (DAA)  formally  accepts  security  responsibility  for  the 
operation  of  the  system  and  officially  declares  that  the  specified  system  will  adequately  protect 
against  compromise,  destruction,  or  unauthorized  modification  under  stated  parameters  of  the 
accreditation.  The  accreditation  decision  affixes  security  responsibility  with  the  DAA  and  shows 
that  due  care  has  been  taken  for  security  in  accordance  with  the  applicable  policies. 

An  accreditation  decision  is  in  effect  after  the  issuance  of  a  formal,  dated  statement  of 
accreditation  signed  by  the  DAA,  and  remains  in  effect  for  the  specified  period  of  time  (varies 
according  to  applicable  policies).  A  system  processing  classified  or  sensitive  unclassified 
information  should  be  accredited  prior  to  operation  or  testing  with  live  data  unless  a  written 
waiver  is  granted  by  the  DAA.  In  some  cases  (e.g.,  when  dealing  with  new  technology,  during  a 
transition  phase,  or  when  additional  time  is  needed  for  more  rigorous  testing),  the  DAA  may  grant 
an  interim  approval  to  operate  for  a  specified  period  of  time.  At  the  end  of  the  specified  time 
period,  the  DAA  must  make  the  final  accreditation  decision. 

Certification  is  conducted  in  support  of  the  accreditation  process.  It  is  the  comprehensive  analysis 
of  both  the  technical  and  nontechnical  security  features  and  other  safeguards  of  a  system  to 
establish  the  extent  to  which  a  particular  system  meets  the  security  requirements  for  its  mission 
and  operational  environment.  A  complete  system  certification  must  consider  factors  dealing  with 
the  system  in  its  unique  environment,  such  as  its  proposed  security  mode  of  operation,  specific 
users,  applications,  data  sensitivity,  system  configuration,  site/facility  location,  and 
interconnections  with  other  systems.  Certification  should  be  done  by  personnel  who  are 
technically  competent  to  assess  the  systems  ability  to  meet  the  security  requirements  according  to 
an  acceptable  methodology.  The  resulting  documentation  of  the  certification  activities  is  provided 
to  the  DAA  to  support  the  accreditation  decision.  Many  security  activities  support  certification, 
such  as  risk  analysis,  security  test  and  evaluation,  and  various  types  of  evaluations. 

Ideally,  certification  and  accreditation  procedures  encompass  the  entire  life  cycle  of  the  system. 
Ideally,  the  DAA  is  involved  from  the  inception  of  the  system  to  ensure  that  the  accreditation 
goals  are  clearly  defined.  A  successful  certification  effort  implies  that  system  security  attributes 
were  measured  and  tested  against  the  threats  of  the  intended  operational  scenarios.  Additionally, 
certification  and  accreditation  are  seen  as  continuing  and  dynamic  processes;  the  security  state  of 
the  system  needs  to  be  tracked  and  assessed  through  changes  to  the  system  and  its  operational 
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environment  Likewise,  the  management  decision  to  accept  the  changing  system  for  continued 
operation  is  an  ongoing  decision  process. 

Standards  for  certification  and  accreditation  services  provide  definitions  and  procedures  for  the 
testing  and  accreditation  of  computer  systems  in  so  far  as  their  conformance  with  security 
standards  is  concerned. 

3.9.7.10.1  Standards.  Table  3.9-46  presents  standards  for  certification  and  accreditation. 


TABLE  3.9-46  Certification  and  accreditation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Touted  Computer  Syitenu  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

CPC 

NIST 

Guideline  for  Computer  Security  Certification  and 
Accreditation 

FIPS  PUB 
102:1983 

Informational 

(Approved) 

— mr 

KSiglll 

MBBI 

'  OHI  irnr-jjy^-  , 
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3.9.7.10.2  Alternate  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.9.7. 10 J3  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  102  does  not  include  services 
for  the  certification  and  accreditation  of  all  modem  security  concepts. 

Certification  and  accreditation  evaluation  criteria  that  address  cuttent  information  technology, 
such  as  distributed  computing  and  networking,  are  needed.  As  new  criteria  such  as  the  Common 
Criteria  emerge,  revision  of  existing  certification  and  accreditation  guidelines  may  be  required. 

3.9.7.10.4  Portability  caveats.  There  are  no  portability  problems  related  to  the  existing 
specifications. 

3.9.7.10.5  Related  standards.  NCSC-TG-029,  "Introduction  to  Certification  and  Accreditation," 
January  1994,  discusses  basic  concepts  related  to  certification  and  accreditation  and  is  the  first  of 
a  series  of  guidelines  in  the  "Rainbow  Series"  supporting  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC)  standard. 

3.9.7.10.6  Recommendations.  The  mandated  standard  is  recommended. 

Procurements  that  require  that  an  AIS  be  certified  and/or  accredited  must  reference  DOD 
Directive  5200.28  and  applicable  designated  approving  authority  guidance.  DOD  Directive 
5200.28,  "Security  Requirements  for  Automated  Information  Systems  (AISs),"  requires 
certification  and  accreditation  of  AIS.  FIPS  PUB  102,  Guidelines  for  Computer  Security  and 
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Accreditation  provides  Federal  guidelines  for  certification  and  accreditation.  Because  of  its  age, 
this  FIPS  PUB  does  not  include  services  for  the  certification  and  accreditation  of  all  modern 
security  concepts.  DOD  5200.28-STD  provides  criteria  to  assess  security  assurances  of  trusted 
systems  to  specific  classes.  DCID  1/16  provides  security  requirements  fi  systems  processing 
intelligence  information. 

The  DISA  CISS  and  NSA  are  each  developing  documents  that  will  standardize  the  certification 
and  accreditation  process  within  DOD.  Each  document  is  in  draft  form;  final  documents  are 
expected  to  be  issued  in  1997.  The  NSA  document,  "Certificatii  n  and  Accreditation  Process 
Handbook  for  Certifiers,"  wil’  be  published  as  a  "Rainbow"  series  document  supporting  the 
TCSEC  standard.  This  NSA  handbook  focuses  on  certification  and  accreditation  of  standalone 
systems.  The  DISA  CIS;,  document,  "DOD  Information  Technology  Certification  and 
Accreditation  Process"  (DITSCAP),  will  be  published  as  a  DOD  publication.  The  DITSCAP 
focuses  on  certification  and  accreditation  in  conjunction  with  the  programmatic  aspects  of  the 
DII. 
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3.9.7.11  Detection  and  notification.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 

Detection  and  notification  objectives  ensure  that  a  secure  system  has  the  capability  to  recognize 
that  it  is:  under  attack;  may  potentially  enter  a  non-available  state;  has  been  compromised;  or  has 
failed  in  a  potentially  compromising  manner.  Guidance  in  this  area  focuses  on  reporting  detected 
security  critical  conditions  to  proper  authorities,  and  implementing  predetermined  corrective 
actions. 

3.9.7.11.1  Standards.  Table  3.9-47  presents  standards  for  detection  and  notification. 


TABLE  3.9-47  Detection  and  notification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trotted  Computer  Syrian*  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

"flc  ' 

SlSSSs! 

O&VimlMFUfe 

"327 

3.9.7.11.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.11.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.11.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.9.7.11.5  Related  standards.  NSA's  C-Technical  Report-001,  Computer  Viruses:  Prevention, 
Detection,  and  Treatment,  and  NIST  SP  800-5,  A  Guide  to  the  Selection  of  Anti-Virus  Tools  and 
Techniques,  provide  guidance  on  computer  viruses.  The  following  specifications  support  the 
TCSEC  standard: 

a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-015,  Version  1,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

c.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.9.7.11.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.9.7.12  Security  recovery.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Recovery 
guidance  defines  provisions  to  allow  system  personnel  or  processes  with  the  proper  authorizations 
to  repair  or  eliminate  the  cause  of  security  relevant  failures,  isolate  compromised  portions  of  the 
system,  and  revalidate  proper  operations  prior  to  returning  the  system  to  a  fully  operational  secure 
state. 

3.9.7.12.1  Standards.  Table  3.9-48  presents  standards  for  security  recovery. 


TABLE  3.9-48  Security  recovery  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Hi 

GPC 

DOD 

The  DOD  Traced  Computer  Systems  Evaluation  Criteria 

DOD  5200.28* 
STD:  1985 

Mandated 

(Approved) 

u 

HEH 

TIiS» 

3.9.7.12.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.12.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.12.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
3.9.7.125  Related  standards.  The  following  specifications  are  related  to  the  TCSEC  standard: 

a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-022,  Version  1,  December  1991,  A  Guide  to  Understanding  Trusted 
Recovery  in  Trusted  Systems 

c.  NCSC-TG-015,  Version  1 ,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

d.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.9.7.12.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.9.7.13  Database  security.  (This  BSA  appears  in  part  4,  part  9,  and  part  10.)  Database 
security  standards  provide  protection  for  stored  data  from  unauthorized  access,  modification,  and 
denial  of  service. 

3.9.7.13.1  Standards.  Table  3.9-49  presents  standards  for  database  security. 


TABLE  3.9-49  Database  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Tnitfed  Computer  Sy  item i  Evaluation  Criteria 

NCSC-TG-021, 
Venion  1: 1991 

Mandated 

(Approved) 

IPC 

ISO 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  127- 
2:1993 

Informational 

(Approved) 

GPC 

NIST 

Information  Resource  Dictionary  Syuem  (IRDS)  (adopu  1 
ANSI  X3. 138-1988  and  X3.138A-I991)  1 

FIPS  PUB 
136:1989 

Informational 

(Appiuved) 

NPC 

ANSI 

Datahaae  Language  SQL 

X3.135-1992 

Informational 

(Approved) 

IPC 

ISO 

Databaae  Language  SQL  (tame  aa  ANSI  X3. 135- 1992) 

9075:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS) 
Framework 

10027:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Service  Definition  for  the  Commitment,  Concurrency, 
and  Recovery  (CCR)  Service  Element 

9804:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Protocol  Specification  for  the  Commitment, 
Concurrency,  and  Recovery  (CCR)  Service  Element 

9805:1990 

Informational 

(Approved) 

NPC 

ANSI 

Information  Reiource  Dictionary  System  (IRDS) 

X3. 138- 1988 

Informational 

(Approved) 

in: 

wm* w> 

|  1:1994 
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3.9.7.13.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.13.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.13.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.9.7.13.5  Related  standards.  DOD  5200.28-STD,  26  December  1995,  DOD  Trusted  Computer 
Systems  Evaluation  Criteria,  is  related  to  NCSC-TG-021.  The  following  specifications  are  related 
to  DOD  5200.28-STD: 

a.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in 
Trusted  Systems 
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b.  NCSC-TO-025,  Version  2,  September  1991 ,  A  Guide  to  Understanding  Data 
Remnants  in  Automated  Information  Systems 

3.9.7.13.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.9.7.14  Security  association  and  key  management.  (This  BSA  appears  in  part  7,  part  9,  and 
part  10.)  A  security  association  is  the  totality  of  communication  and  security  mechanisms  and 
functions  (e.g.,  communications  protocols,  security  protocols,  doctrinal  mechanisms,  security- 
critical  mechanisms  and  functions)  that  securely  binds  together  two  security  contexts  in  different 
end  systems  or  relay  systems  supporting  the  same  information  domain.  A  security  association  is  an 
application  association  that  includes  additional  support  from  security  functions  and  mechanisms. 
Key  management  provides  procedures  for  handling  cryptographic  keying  material  to  be  used  in 
symmetric  or  asymmetric  cryptographic  mechanisms.  It  includes  key  generation,  key  distribution, 
key  storage,  key  archiving,  and  key  deletion. 

3.9.7.14.1  Standards.  Table  3.9-50  presents  standards  for  security  association  and  key 
management 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NSA 

Key  Exchange  Algorithm 

R21-TECH-23-94: 

1994 

Mandated 

(Approved) 

GPC 

NSA 

Socui;  DaU  Network  System  (SDNS)  Key  Management 
Protocol  (KMP) 

SDN.903.  Version 
3.2:  1989 

Mandated 

(Approved) 

GPC 

NIST 

Key  Management  Using  ANSI  X9.17 

FIPS  PUB 
171:1992 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview. 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  2:Security 
Exchange  Service  Element  Definition 

11586-2:1994 

Informational 

(Approved) 

[PC 

ISO 

Generic  Upper  Layer  Security  (GULS)  .part  3:  Security 
Exchange  Service  Element  Protocol  Specification 

11586-3:1994 

Informational 

(Approved) 

IPC 

ISO 

Banking  Key  Management  (wholesale) 

8732:1988 

Informational 

(Approved) 

Informational 

(Approved) 
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3.9.7.14 2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.9.7.14.3  Standards  deficiencies.  There  is  a  lack  of  guidance  for  establishing  a  Public  Key 
Infrastructure  (PKI)  to  automatically  manage  public  keys  through  the  use  of  public  key 
certificates.  In  April  1994,  NIST,  in  conjunction  with  seven  other  federal  agencies,  completed  a 
study  on  automated  management  of  public  keys  and  associated  public  key  certificates  on  a 
nationwide  basis.  Based  on  the  recommendations  of  the  study,  NIST  is  establishing  a  PKI  pilot 
project  to  provide  public  key  certificate  services  for  several  participating  government  agencies. 

3.9.7.14.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.7.14.5  Related  standards.  There  are  no  related  standards. 

3.9.7.14.6  Recommendations.  The  mandated  standards  are  lecommended.  In  FORTEZZA 
applications,  the  NSA-developed  Key  Exchange  Algorithm,  R21 -TECH-23-94,  must  be  used. 

IEEE  P1363,  Standard  for  Public-Key  Cryptography,  is  under  development,  with  the  first  version 
expected  to  be  ready  for  balloting  in  1997. 

The  lETF's  IP  Security  Protocol  (IPSEC)  Working  Group  (WG)  is  developing  an  Internet  Key 
Management  Protocol  (IKMP)  that  will  be  specified  as  an  application  layer  protocol  independent 
of  the  lower  layer  security  protocol.  The  IKMP  will  be  based  on  ISAKMP/Oakley  work  begun  in 
the  Internet  Draft  documents  for  ISAKMP  and  the  Oakley  Key  Determination  Protocol. 
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3.9.7.15  Registration  of  cryptographic  techniques.  (This  BSA  appears  in  part  9  and  part  10.) 
These  standards  provide  procedures  for  the  registration  of  cryptographic  algorithms  in  a  standard 
format  with  a  registration  authority.  The  need  for  these  registration  services  is  determined  by  the 
security  architecture  of  the  system  in  question.  These  are  not  implementable  specifications  and  no 
conformance  test  is  required. 

3.9.7.15.1  Standards.  Table  3.9-51  presents  standards  for  registration  of  cryptographic 
techniques. 


TABLE  3.9-51  Registration  of  cryptographic  techniques  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPG 

ISO 

Procedure!  for  the  Regiitrahon  of  Cryptographic 
Algorithm! 

9979:1991 

Information*! 

(Approved) 

3.9.7.15.2  Alternate  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.9.7.15.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.9.7.15.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.9.7.15.5  Related  standards.  No  standards  are  related  to  registration  of  cryptographic 
techniques. 

3.9.7.15.6  Recommendations.  Procurements  requiring  that  all  cryptographic  algorithms  offered 
are  registered  with  a  registration  authority  in  a  standard  format  should  specify  conformance  with 
ISO  9979.  The  NIST  document,  N1STIR  5308,  "General  Procedures  for  Registering  Computer 
Security  Objects,"  December  1993,  describes  the  object-independent  procedures  for  operating  the 
Computer  Security  Objects  Register  (CSOR)  established  by  NIST.  Initially,  the  only  family  of 
objects  registered  in  the  CSOR  is  network  security  labels;  however,  plans  include  adding 
cryptographic  algorithm  modes  of  operation  to  the  CSOR. 


April  7,  1997 


3.9-110 


Version  3.1 


Mommian  Technology  Standards  Gaidai 


System  Management  Services 


3.9.8  Other  manage mert  services. 

3.9.8.1  Database  administration.  (This  BSA  appears  in  part  4  and  part  9.)  Data  administration 
is  the  process  of  the  analysis,  classification,  and  maintenance  of  an  organization's  data  and  data 
relationships.  It  includes  the  development  of  data  models,  data  warehousing,  and  data  dictionaries, 
which  combined  with  transaction  processing,  are  the  raw  materials  for  database  design. 

3.9.8.1.1  Standards.  Table  3.9-S2  presents  standards  for  database  administration. 


TABLE  3.9-52  Database  administration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Data  Element  Standardization  Procedure*,  January  1993 

Mandated 

(Approved) 

GPC 

NIST 

Guide  to  Data  Entity  Naming  Convention* 

NBSSP  500-149  of 
Oct.  1987 

Informational 

(Approved) 

GPC 

UOD 

Defense  Data  Repod  lory  System 

End  Uier  Manual 
ver.  2.0  of  10 
August  1993 

Informational 

(Approved) 

B*C 

ISO/IEC 

Specification  and  Standardization  of  Dal  t  Element*,  Put  3: 
Bade  Attribute*  of  Data  Element* 

11179-3:1994 

Informational 

(Approved) 

tPC 

ISO/IEC 

Specification  and  Standardization  of  Data  Element*,  Part  4: 
Rule*  and  Guideline*  for  the  Formulation  of  Data 
Definitions 

11179-4:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Specification  and  Standardization  of  Data  Element*.  Part  3: 
N  ming  and  Identification  Principle*  for  Data  Element* 

11179-5:1995 

Informational 

(Approved) 
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3.9.8.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary 
database  utilities. 

3.9.8.U  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard. 

3.9.8.1.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist. 

3.9.8.1.5  Related  standards.  The  following  standards  are  related  to  database  administration  or 
database  administration  standards: 

a.  ISO  7498-4: 1 989:  Management  Framework 

b.  ISO  9075:  SQL 

c.  ISO  9579- 1 :  RDA  (Generic  Model,  Service  and  Protocols) 

d.  ISO  9579-2:  RDA  (SQL  Specialization) 

e.  ISO  9595:1991:  CMIS. 
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f.  ISO  9596-1:1991:  CMIP. 

g.  ISO/IEC  9945-1:  (IEEE  P1003.1) 

h.  ISO  10164-1:1993:  Object  Management  Function 

i.  ISO  10165-1:1991:  SMI  -  Part  1  Management  Information  Model 

j.  ISO  10165-2:1991:  SSMI  -  Part  2  DMI 

k.  ISO  10165-4: 1992:  Guidelines  for  the  Definition  of  Managed  Objects  (GDMO) 

l.  ANSI  X3.135-1992:  SQL 

m.  ANSI  X3.168-1989:  Embedded  SQL 

n.  NIST  FIPS  127-2:  Database  Language  SQL 

o.  NIST  FIPS  146-1:  Government  Open  Systems  Interconnection  Profile  (GOSIP) 

p.  NIST  FIPS  156:  HRDS 

q.  NIST  FIPS  193:  SQL  Environments 

3.9.8.1.6  Recommendations.  DODD  8320. 1  is  recommended  for  data  administration.  Database 
administration  systems  should  be  compatible  with  and  integrated  with  the  SQL  database  language 
set  forth  in  FIPS  PUB  127-2.  Furthermore,  all  database  administration  systems  offered  as  a  result 
of  this  procurement's  requirements  shall  be  integrated  with  ISO  9579-1  RDA  (Generic  Model, 
Service  and  Protocol),  ISO  9579-2  Remote  Database  Access  (SQL  Specialization)  of  December 
1993,  and  NIST  FIPS  PUB  193,  SQL  Environments. 
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3.9.8.2  Object-oriented  database  management.  (This  BSA  appears  in  both  Part  4  and  Part  9.) 
Standards  for  object-oriented  database  management  provide  facilities  and  interfaces  to  manage 
object  databases  (databases  that  store,  manipulate,  and  retrieve  data  represented  as  objects). 

3.9.8. 2.1  Standards.  Table  3.9-33  presents  standards  for  object-oriented  database  management. 


TABLE  3.9-53  Object-oriented  database  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

ODMG 

Object  Database  Management  Group  (ODMG)  -  93 

ODMG-93,  Release 
1.1 

Informational 

(Approved) 

ODM 

1 

I 

c»c 

«  X 

OMB 

<*^«**r 

1 

3.9.8.2.2  Alternative  specifications.  Microsoft's  Object  Database  Connectivity  (OBDC)  API 
specification  for  MS-Windows  applications  is  also  available. 

3.9.8.2  J  Standards  deficiencies.  Deficiencies  in  the  standards  are  unknown,  since  these  services 
are  not  part  of  any  formal  standard,  but  the  Microsoft  specification  has  insufficient  drivers 
available. 

3.9.8.2.4  Portability  caveats.  This  is  a  high  portability  risk  area  because  no  standards  exist,  and 
many  Microsoft  PC  products  do  not  comply  with  most  Unix-  and  Portable  Operating  System 
Interfaces  for  Computers  (POSIX)-based  systems. 

3.9.8.2.5  Related  standards.  No  standards  are  related  to  object-oriented  database  management 
standards. 

3.9.8.2.6  Recommendations.  There  is  no  recommendation  at  this  time. 
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3.9.83  Floppy  disk  format  and  handling.  (This  BSA  appears  both  in  part  8  and  part  9.) 
Floppy  disk  format  and  handling  standards  provide  formats  and  interfaces  for  the  exchange, 
backup,  and  restoration  of  data  to  or  from  floppy  disks. 

3.9.8.3.1  Standards.  Table  3.9-54  presents  standards  for  floppy  disk  format  and  handling. 


TABLE  3.9-54  Floppy  disk  format  and  handling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/EEC 

9945-1:1996 

Mandated 

(Approved) 

IPC 

ISO/ffiC 

Information  Technology  -  Portable  Operating  Synem 
Interface  (POSIX)  -  Part  2:  Shelf  and  Utilities  (u  profiled 
by  FIPS  PUB  189:19941 

9945-2:1993 

Mandated 

(Aumved) 

CPN-C 

Microioft 

Window  Management  and  Graphic*  Device  Interface, 
Volume  1  Microtoft  Win32  Progiammen'  Reference 
Manual.  1993.  Microtoft  Pre*» 

Win32  API* 

Mandated 

(Approved) 

CPC 

X/Opeti 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Udlidea,  Iitue  4,  Veoion  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

GPC 

NIST 

Informational 

(Approved) 

iiifiili 

MHM 

1 

wmM _ I 

Mi 

safes  m 

jg| 

1 

1 

! 

3.9.8.3.2  Alternative  specifications.  The  following  alternative  specifications  are  also  available: 

a.  Sun  Microsystems’  SunOS/Solaris  command  "bar" 

b.  OSF:  OSF/1  "tar"  and  "cpio"  utilities. 

3.9.8.3.3  Standards  deficiencies.  POSIX  and  Unix  have  very  poor  floppy  disk  handling 
capabilities.  Most  standards  related  to  floppy  disks  concern  logical  interfaces  that  permit  the 
interconnection  of  floppy  disk  peripherals. 

3.9.8.3.4  Portability  caveats.  The  "bar"  is  not  a  standard.  However,  it  is  widely  used  because  of 
Sun's  large  installed  base.  It  is  presented  as  an  example  of  a  capability  needing  to  be  standardized, 
as  well  as  an  example  of  the  kind  of  capability  that  could  be  specified. 

3.9.8.3.5  Related  standards.  No  standards  are  related  to  floppy  disk  format  standards. 

3.9.8.3.6  Recommendations.  ISO/1EC  9945-2  disk  format  services  "pax"  are  expected  to  replace 
"tar"  and  "cpio"  utilities  in  POSIX. 1.  X/Open  SUS  includes  the  POS1X.2  utilities. 
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3.9.8.4  POSIX  tape  labeling  and  tape  voluine  processing.  (This  BSA  appears  both  in  part  8 
and  part  9.)  Tape  labels  are  a  fixed  portion  of  data  stored  on  tape  media  and  containing  certain 
types  of  administrative  information  automatically  readable  by  tape-handling  software.  Among  the 
information  typically  stored  on  tape  labels  are  the  identification  of  the  media  content,  ownership 
of  the  media  content,  access  control  information  for  the  media  content,  and  the  format  of  the  rest 
of  the  information  on  the  media. 

3.9.8.4.1  Standards.  Table  3.9-55  presents  standards  for  POSIX  tape  labeling  and  tape  volume 
processing. 


TABLE  3.9-55  POSIX  tape  labeling  and  tape  volume  processing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

rpc 

BCMA 

File  Structure  and  Labeling  of  Magnetic  Tape*  for 
Information  Interchange 

13  (1985) 

Informational 

(Approved) 

IPC 

ECMA 

Magnetic  Tape  Caiiette  Labeling  and  File  Structure  for 
Information  Interchange 

41  (1973) 

Informational 

(Approved) 

MC 

. 1 

mm 

TOPIC  hBtij»IW»AiW-A«nwWl  wit  SytfMft API 
awwmCtawWM 

TWM* 

<££> 
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>  N  i  \  ,  ,  >  s  %  . .  ..  '  ■■  -*  ■-  . 

3.9.S.4.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 

3.9.8.4J  Standards  deficiencies.  The  P1003.1a  draft  standard  does  not  address  the  issue  of 
processing  several  files  as  if  they  were  a  single  entity. 

Traditional  Unix  systems  do  not  provide  mechanisms  for  protected  access  to  devices  or  media, 
nor  do  they  generally  provide  mechanisms  for  label  processing  or  transparent  volume  switching. 

3.9.8.4.4  Portability  caveats.  To  provide  tape  handling  portability,  a  standard  must  specify  the 
handling  of  ANSI/ISO  labeled  tape  and  IBM  labeled  tape.  IBM  labeled  tapes,  although  not  a 
strict  standard,  represent  vast  numbers  of  labeled  tapes  already  in  existence.  IBM  labeled  tapes 
are  roughly  analogous  to  the  ANSI  standard,  except  the  labels  are  written  with  the  EBCDIC 
character  set  rather  than  with  ASCII. 

It  is  not  certain,  even  within  the  proposed  standard,  how  to  process  information  when  some  of  it 
is  on  9-track  tape  and  some  on  8mm  (Exabyte)  tape,  or  some  on  labeled  and  some  on  unlabeled 
tape.  This  may  be  a  limitation  of  the  standard. 

3.9.5.4.5  Related  standards.  The  following  standards  are  related  to  POSIX  tape  labeling  and 
tape  volume  processing  standards: 

a.  1SO/IEC  9945- 1 : 1996:  POSIX  Part  1 :  System  Application  Programming  Interface. 

b.  ISO/IEC  9945-2:1992:  POSIX  Part  2:  Shell  and  Utility. 
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c.  IEEE  1003.5;  1992:  Ada  Language  Binding  to  POSIX. 

d.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

e.  IEEE  P1387.1:  POSIX  System  Administration  -  Part  1:  Overview. 

f.  IEEE  1003.9: 1992:  Standard  Fortran  Language  Bindings  to  POSIX. 

3.9.8.4.6  Recommendations.  There  are  no  recommendations. 
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3.9.8.S  Print  management  (This  BSA  appears  both  in  part  8  and  part  9.)  The  print  services  are 
used  by  management  and  user  applications  to  send  a  file  to  the  printer,  cancel  the  print  job,  and 
get  printer  status  information.  The  printing  systems  program  interface  is  used  as  the  base  for  the 
POSIX  printing  management  standard.  Printing  management  standards  also  provide  services  and 
interfaces  for  transparent  remote  printing,  output  spooling,  spool  queue  management,  and 
scheduling. 

3.9.8.5.1  Standards.  Table  3.9-S6  presents  standards  for  print  management. 


TABLE  3.9-56  Print  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

f 'Htus 
DcD 

(Lifecycle) 

IPC 

ISO/IEC 

Information  Technology  -  Portable  Operating  System 
Interface  (POSIX)  -  Part  2:  Shell  and  Utilities  (as  profiled 
bv  FIPS  PUB  189:1994) 

9945-2:1993 

Mandated 

(Approved) 

CPC 

X/Open 

Common  Desktop  Environment  (CDE);  XCDE  Services 
and  Applications 

C323  (4/95) 

Misdated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphics  Device  Interface, 
Volume  1  Microsoft  Win32  Programmers  Reference 
Manual,  1993.  Microsoft  Pres* 

Win32  APIs 

Mandated 

(Approved) 

CPC 

X/Open 

Single  UNIX  Specification  (Spec.  1 170)  Command*  and 
Utilities,  Issue  4,  Version  2  (part  of  XPG4) 

C436  (9/94) 

Emerging 

(Approved) 

IPC 

ECMA 

Method  for  Measuring  Printer  Throughput 

132(1991) 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Test  and  office  system*  • 
Document  Printing  Application  (DPA).  Part  1:  Abstract 
service  definition  and  procedures 

10175-1:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Technology  -  Text  and  office  systems  - 
Document  Printing  Application  (DPA)  •  Part  2:  Protocol 
specification 

10175-2:1996 

Informational 

(Approved) 

** 
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3.9.5.5.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  MIT:  Palladium  (the  basis  for  DME  print  management). 

b.  Berkeley  4.2/4.3  Unix. 

c.  Siemens/Nixdorf:  Priming  Management  (the  basis  for  UI's  distributed  printing 
management  specification  and  USL's  reference  implementation). 

3.9.8.5.3  Standards  deficiencies.  SVID,  OSF/1 ,  and  Berkeley  Unix  have  no  features  to  control 
the  formatting  or  scheduling  of  print  jobs.  The  SVID,  OSF/1,  and  Berkeley  Unix  are  designed  for 
centralized  environments.  No  Ada  bindings  exist  for  print  management  standards.  POSIX. 2 
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specifies  only  a  minimal  "lp"  command,  suitable  for  submitting  print  jobs;  no  printer 
administration  facilities  are  provided. 

3.9.8.S.4  Portability  caveats.  The  System  V  Unix  “lp”  printing  system,  from  which  the  POSIX 
"lp"  command  is  derived,  is  not  compatible  with  the  Berkeley  Unix  “lpr"  printing  system. 

The  OSF  DME  distributed  print  management  is  based  on  MITs  Palladium.  It  has  a  different 
interface  from  UI/USL's  distributed  print  management,  which  is  based  on  the  Siemens-Nixdorf 
Xprint  program  and,  therefore,  is  incompatible. 

3.9.&5.5  Related  standards.  The  following  standards  are  related  to  print  management  services 
or  standards; 


a.  ISO/IEC  9945-1:1996:  POSIX  Part  1  -  System  Application  Programming 
Interface. 

b.  ISO  8824:1990:  Abstract  Syntax  Notation  1  (ASN.l). 

c.  ISO  8825: 1990:  Basic  Encoding  Rules  for  ASN.  1 . 

d.  ISO  9072: 1989:  Remote  Operations  Service  Element  (ROSE). 

e.  ISO/IEC  9595:  Common  Management  Information  Service  (CMIS). 

f.  ISO/IEC  9596:  Common  Management  Information  Protocol  (CMIP). 

g.  ISO/IEC  DIS  1 1578.2:  Remote  Procedure  Call. 

h.  IEEE  P 1003.  le:  Security  Interface  Standards  for  POSIX. 

i.  Internet  RFC  1 155:  Structure  and  Identification  of  Management  Information  for 
TCP/IP-based  Internets. 

j.  Internet  RFC  1157:  Simple  Network  Management  Protocol. 

k.  Internet  RFC  1158:  Management  Information  Base  for  Network  Management  of 
TCP/IP-based  Internets  (MIB-II). 

l.  Network  Management  Forum:  OMNIPoint  1. 

3.9.8.S.6  Recommendations.  The  recommendation  is  to  specify  POSIX  "lp"  only  for  traditional, 
centralized  systems  for  imminent  procurements.  Then  look  to  ISO  10175  or  IEEE  1 387.4  in  the 
long  term. 
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3.9.9  Additional  areas  to  be  added.  The  following  Open  Systems  Operations,  Administration, 
and  Maintenance  services  are  under  consideration  for  addition: 

a.  Problem  reporting  and  tracking  standards 

b.  Operations  standards 

c.  Diagnostic  standards 

d.  Fault  isolation  standards 

e.  System  performance  metrics  and  standards 

f.  Standard  mechanisms  to  initiate  remotely  both  OSE  and  proprietary  diagnostics 

g.  End  user  support  (help  desks) 

h.  Systems  integration  standards 
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3.10  Security  services.  The  security  services  portion  of  the  ITSG  presents  standards,  guidelines, 
models,  frameworks,  and  other  documents  related  to  the  protection  of  information  that  is  stored, 
transferred,  or  processed  in  automated  systems.  Use  and  compliance  with  the  security  standards 
identified  in  this  document  do  not  constitute  authorization  to  process  classified  data.  DOD  policy 
covering  the  accreditation  process  must  still  be  adhered  to  in  order  to  obtain  approval  for 
processing  of  classified  data. 

3.10.1  Introduction  and  overview  of  security  services.  Security  represents  a  cross-functional 
area  in  the  ITSG.  Consequently  the  security  services  identified  in  this  part  of  the  ITSG  can  be 
found  in  other  parts  as  well.  The  intent  of  this  chapter  is  to  provide  a  single  location  where  one 
can  go  to  identify  the  standards,  guidelines,  etc.  related  to  any  pertinent  security  service  area.  All 
security-related  BSAs  in  ITSG,  Part  10  are  "grounded"  in  the  security  service  area;  that  is,  the 
security  service  area  is  the  foundation  for  all  security  BSAs.  In  turn,  each  security  BSA  is 
"cloned"  into  at  least  one  other  service  area.  The  discussion  and  recommendations  for  these 
cloned  BSAs  are  identical  to  that  contained  in  Part  10,  Security  Services,  and  the  standards  tables 
for  the  cloned  security  BSAs  are  identical  to  the  standards  tables  for  the  corresponding  BSAs  in 
Part  10.  The  presentation  of  this  chapter  is  guided  by  two  concerns.  The  first  is  to  be  consistent 
with  the  security  principles  and  concepts  of  the  DOD  Goal  Security  Architecture  (DGSA).  Thus 
sections  3. 10.4  through  3. 10.9  correspond  to  the  security  services  presented  in  the  DGSA.  The 
second  is  to  provide  an  overview  of  the  major  security  architectures,  applications,  and 
management  concerns  to  ITSG  users  at  all  levels  of  expertise  (sections  3. 10.2  and  3. 10.3). 

For  users  of  the  ITSG  who  are  not  familiar  with  security  terminology,  the  following  references  are 
suggested: 

a.  National  Information  Systems  Security  (INFOSEC)  Glossary,  National  Security 
Telecommunications  and  Information  Systems  Security  (NTISSI)  No.  4009,  5 
June  1992. 

b.  Glossary  of  Telecommunications  Terms,  FED-STD-1037B,  3  June  1991. 

c.  Dictionary  of  Information  Systems,  ANSI  X3.172,  1990. 

d.  Security  in  Open  Systems  -  Data  Elements  and  Service  Definitions,  ECMA 
138:1989  (based  on  ECMA  TR46:1988). 

e.  Glossary  of  Computer  Security  Terms,  NCSC-TG-004,  version  1,21  October 
1988. 

NOTE:  Throughout  Part  10,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  IPC 

c.  Government  Public  Consensus  =  GPC 
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d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3.10.2  Architectures  and  applications.  Standards,  guidance,  and  frameworks  that  help  to  define 
security  architectures  and  the  placement  of  security  into  specific  applications,  are  intended  to 
provide  guidance  to  standards  developers.  They  do  not  provide  implementable  specifications 
against  which  conformance  can  be  claimed. 

3.10.2.1  Security  models  and  architectures.  (This  BSA  appears  in  part  2  and  part  10.) 

Security  models  provide  the  necessary  basis  for  the  development  of  security-related  protocols  and 
security-related  protocol  elements. 

3.10.2.1.1  Standards.  Table  3.10-1  presents  standards  for  security  models  and  architectures. 


TABLE  3.10-1  Security  models  and  architectures  standards 


Standard 

Type 

Sponsor 

IPC 

ISO 

CPC 

CEN/CENELEC/ 
IT AEG  V 

IPC 

ECMA 

IPC 

ECMA 

GPC 

NIST 

IPC 

ITU-T 

CPC 

XyOpm 

IPC 

ITU-T 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO/lEC 

IPC 

ISO/IEC 

IPC 

ISO/lEC 

IPC 

ISO 

CPC 

X/Open 

Standard 


Taxonomy  of  Security  Standardization 


Security  in  Open  System*  -  Data  Elements  and  Service 
Definitions 


Security  in  Open  Systems  -  A  Security  Frameworic 


Standard 

Reference 


ITAECJV  N69  Ver 
2  of  4/30/W92 


138 (1989) 


TR/46  0988) 


Guideline*  for  Security  of  Computer  Applications  FIPS  PUB  73:1980 


Security  Architecture  for  OSI  for  CCITT  Applications :  X.800  ( 1 99 1 ) 

Security,  Structure,  and  Applications 


Security  Guide  (Second  Edition) 


Reference  Model  of  OSE  for  CCITT  Appbcatiofu-Data  X.200  ( 1989) 
Communication!  Netwoifci-QSl  Model  and  Notation, 

Services  Definition 


OSI  Basic  Reference  Model,  Part  3:  Naming  and 
Addreiiing 


OSI  Basic  Reference  Model,  Pan  4:  Management 
Frameworic 


OSI  The  Directory:  Procedure!  for  Distributed 
Operationi:(same  as  ITU-T  X.519(1993» 


7498-3:1989 


7498-4:1989 


9594-3:1993  (or 
1994) 


9594-4:1993  (or 
1994) 


OSI  The  Directory:  Authentication  Framework  (time  as  9594-8: 1993  (or 
ITU-T  X.509  (1993))  1994) 


OSI  Upper  Layer  Security  Model 


Distributed  Security  Framework 


10745:1993 


0410(12/94) 


jiformational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(ARJroved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1.0 

CC  Venion  1.0: 
1996 

Emerging 

(Draft) 

NPC 

rPPP 

Guide  to  the  POSIX  Open  System*  Environment  -  A 
Security  Framework 

PI 003.22: 1995 

informational 

(Draft) 

IPC 

ISOAEC 

OS!  Security  Framewoifcj  tor  Open  Systenu,  Part  1: 
Overview 

10181-1 

InfotmabonaJ 

(Draft) 

IPC 

ISO/IEC 

Guide  to  Open  System*  Security 

TR  by 

JTC1/SC21/N8380 

Informational 

(Draft) 

IPC 

ISO/EC 

Management  Plan  for  Security 

JTC1/5C21  SD-7 

Informational 

(Draft) 

3.10.2.1.2  Alternative  specifications.  There  are  no  alternate  specifications. 

3,10.2.13  Standards  deficiencies.  FIPS  PUB  73  does  not  include  information  about  modern 
security  concepts. 

3.10.2.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
3.10.2.15  Related  standards.  There  are  no  related  standards. 

3.10.2.1.6  Recommendations.  The  DGSA,  Volume  6  of  the  TAFIM,  is  the  abstract  and  generic 
security  architecture  of  the  TAFIM.  The  DGSA  provides  security  principles  and  target  security 
capabilities  to  guide  system  security  architects  in  creating  specific  security  architectures  consistent 
with  the  DGSA.  The  DGSA  should  be  used  by  system  security  architects  to  develop  logical  and 
specific  security  architectures. 


April  7,  1997 


3.10-3 


Version  3.1 


3.10.2.2  System  development.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Development 
of  secure  systems  requires  that  security  engineering  be  a  key  discipline  in  conjunction  with  other 
system,  software,  and  hardware  engineering  activities. 

3.1022.1  Standards.  Table  3.10-2  presents  standards  for  system  development 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

HU 

GPC 

DOD 

The  DOD  Trotted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trotted  Network  Interpretation 

NCSC-TG-005, 
Version  1: 1987 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-021, 
Version  1: 1991 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Cryptologic  Programmers'  Guide 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Application  Implementors'  Guide 

MD4 0021 01- 1.52: 
1996 

Mandated 

(Approved) 

GPC 

DOD 

Software  Development  and  Documentation 

MIL-STD-498 

Informational 

(Approved) 

IPC 

ISO/IEC 

Software  Life  Cycle  Processes 

12207:1995 

Informational 

(Approved) 

NPC 

HA 

Trial  Use  Standard  -  Standard  for  Information  Technology 
•  Software  Life- Cycle  Processes  -  Software  Development  - 
Acquirer-Supplier  Agreement 

EIA/IEEE  J-STD- 
016:  1995 

Informational 
(A  proved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

HKSSSgifiSi 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Guidelines  for  Security  of  Computer  Applications 

FIPS  PUB  83:1980 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory:  Abstract  Service  Definition:  (same  as 

ITU-T  X.5  II  (1993)) 

9594-3:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory:  Procedures  for  Distributed 
Operations :(same  as  ITU-T  X.5 19(1 993)) 

9594-4:1993  (or 
1994) 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  The  Directory:  Authentication  Framework  (same  as 

ITU-T  X. 509  (1993)) 

9594-8:1993  (or 
1994) 

Informational 

(Approved) 

CPC 

X/Open 

Generic  Security  Service  API  (GSS-APD  Base 

C44I  (12fl5) 

Informational 

(Approved) 

NPC 

IEEE 

POSIX,  Part  l :  System  API  -  Amendment  n:  Protection, 
Audit,  and  Control  Interfaces  (C  Language),  Draft  15 

PI  003.  le:  1995 

Legacy 

(Draft) 

NPC 

IEEE 

POSIX  Part  2:  Shell  and  Utilities  -  Amendment  n: 
Protection  and  Control  Utilities,  Draft  15 

P1003,2c:  1995 

Emerging 

(Draft) 

CPC 

IETF 

Generic  Security  Service  -  Application  Program  Interface, 
Version  2 

RFC  2078:  1997 

Emerging 

(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

IETF 

Independent  Data  Unit  Protection  Geoeric  Security 
Application  Program  Interface  flDUP-GSS-API) 

Emerging 

(Draft) 

NPC 

IEEE 

Standard  for  Information  Technology  -  Software  Life  Cyde 
Processes 

IEEE/EIA 

12207US-date 

Informational 

(Draft) 

NPC 

IFFF 

Guide  for  Information  Technology  -  Software  Life  Cyde 
Pincette*  -  Life  Cyde  Data 

IEEE/EIA 
12207.1  US-date 

Informational 

(Draft) 

NPC 

TFFF 

Guide  tor  information  Technology  •  Software  Life  Cyde 
Pioceuea  -  Implementation  Conti  derations 

IEEE/EIA 

12207.2US.date 

Informational 

(Draft) 

3.10.2.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.2.2  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.2.2.4  Portability  caveats.  There  are  no  portability  caveats. 

3.10.2.2.5  Related  standards.  DOD  Directive  5200.28  "Security  Requirements  for  Automated 
Information  Systems  (AISs),"  provides  the  DOD-wide  program  for  AIS  security.  It  provides 
mandatory,  minimum  AIS  security  requirements  for  systems  processing  classified,  sensitive  but 
unclassified,  and  unclassified  information.  For  intelligence  systems.  Director,  Central  Intelligence 
Directive  (DCID)  1/16,  "Security  Policy  for  Uniform  Protection  of  Intelligence  Processed  in 
Automated  Information  Systems  and  Networks,"  and  "Security  Manual  for  Uniform  Protection  of 
Intelligence  Information  Processed  in  Automated  Information  Systems  and  Networks,"  should  be 
used  in  conjunction  with  DOD  5200.28-STD.  The  following  guidelines  also  are  for  use  with 
DOD  5200.28-STD: 

a.  NCSC-TG-006,  Version  1,  28  March  1988,  A  Guide  to  Understanding 
Configuration  Management  in  Trusted  Systems 

b.  NCSC-TG-007,  Version  1, 2  October  1988,  A  Guide  to  Understanding  Design 
Documentation  in  Trusted  Systems 

c.  NCSC-TG-008,  Version  1,  15  December  1988,  A  Guide  to  Understanding  Trusted 
Distribution  in  Trusted  Systems 

d.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in 
Trusted  Systems 

e.  NCSC-TG-023,  Version  1,  July  1993,  A  Guide  to  Understanding  Security  Testing 
and  Test  Documentation  in  Trusted  Systems 

3.10.2.2.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 
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MIL-STD-498  merges  and  supersedes  DOD-STD-2167A  and  DOD-STD-7935A  and  has  been 
approved  for  use  by  DOD  with  a  waiver.  Requirements  for  usage  waivers  are  determined  by  each 
Service  or  Agency.  MIL-STD-498  contains  requirements  for  security  and  privacy  for  software 
development  and  documentation.  EIA/IEEE  J-STD-016:  1995  (formerly  IEEE  1498/ELA  IS  640) 
is  based  on  MIL-STD-498  and  was  issued  30  September  1995  as  a  joint  EIA/IEEE  trial  use 
standard.  It  is  anticipated  that  J-STD-016  will  be  upgraded  from  trial  use  to  full  use  and  issued  as 
an  ANSI  standard  in  1997.  It  is  also  anticipated  that  IEEE/EIA  12207US,  the  U.S.  adaptation  of 
ISO/IEC  12207,  will  be  sent  to  ANSI  as  a  joint  standard.  IEEE/EIA  12207US  will  consist  of  a 
base  standard  (12207 .OUS)  and  two  guides  (12207.1US  and  12207.2US).  The  base  standard  will 
contain  ISOAEC  12207  and  is  expected  to  be  approved  prior  to  July  1997.  The  guide  IEEE/EIA 
12207. 1US,  Guide  for  Information  Technology  -  Software  Life  Cycle  Processes  -  Life  Cycle 
Data,  will  contain  the  contents  lists  of  the  product  descriptions  from  EIA/IEEE  J-STD-016.  The 
guide  IEEE/EIA  12207.2US  will  provide  guidance  for:  software  reuse,  software  process 
management  indicator  categories  for  problem  reporting,  software/system  architecture, 
development  strategies,  tailoring  and  build  planning,  software  product  evaluations,  alternate 
means  of  compliance  for  joint  reviews,  configuration  managr*  .••>.- r  --".d ;  x.  imr-supplier 
interaction.  The  two  guides  are  expected  to  be  final  by  Sepf.i-cr  1  ■  i  ,v  ,-n?  range  goal  is 

migration  to  full  use  of  IEEE/EIA  12207US;  however,  ElA/s;'.£C  j-STD-Uia  i;«  i  <>;  for 
transition  from  MIL-STD-498,  subject  to  Agency/Service  approval,  until  organization- 1 ;  r..c  -vsrs 
for  IEEE/EIA  12207US  are  in  place. 

If  FORTEZZA  services  are  used,  the  following  two  guidelines  should  be  consulted: 

a.  MD4002101-1.52, 3/5/96,  FORTEZZA  Application  Implementors’  Guide 

b.  MD4000502-1.52,  1/30/96,  FORTEZZA  Cryptologic  Programmers'  Guide, 
Revision  1.52 
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3.10.2.3  Database  security.  (This  BSA  «ars  in  part  4,  part  9,  and  part  10.)  Database 
security  standards  provide  protection  for  stored  data  from  unauthorized  access,  modification,  and 
denial  of  service. 

3.10.2 .31  StarJards.  Table  3.10-3  presents  standards  for  database  security. 


TABLE  3.10-3  Database  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Tnuted  Database  Management  Sy  Mem  Interpretation  of  the 
T ruled  Computer  Syuenu  Evaluation  Criteria 

NCSC-7X5-G2I, 
Version  1:  1991 

Mandated 

(Approved) 

IPC 

ISO 

OS I  Basic  Reference  Mode],  Part  2:  Security  Architecture 
(same  as  CCITT  X.800: 1991) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Database  Language  SQL  (Adopts  ANSI  X3.135-1992 
(same  as  ISO  9075: 1992)) 

FIPS  PUB  127- 

2:1993 

Informational 

(Approved) 

GPC 

NIST 

Information  Resource  Dictionary  System  (IRDS)  (adopts 
ANSI  X3. 138- 1988  and  X3.138A-199I) 

FIPS  PUB 
156:1989 

Informational 

(Approved) 

NPC 

ANSI 

Database  Language  SQL 

X3. 135- 1992 

Informational 

(Approved) 

IPC 

ISO 

Database  Language  SQL  (same  as  ANSI  X3. 135- 1992) 

9075:1*92 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS) 

Frame  wo  ik 

10027:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Service  Definition  for  the  Commitment,  Concurrency, 
and  Recovery  (CCR)  Service  Element 

9804:1990 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Protocol  Specification  for  the  Commitment, 
Concurrency,  and  Recovery  (CCR)  Service  Element 

9805:1990 

Informational 

(Approved) 

NPC 

ANSI 

Information  Resource  Dictionary  System  (IRDS) 

X3.138-1988 

Informational 

(Approved) 

IPC 

ISO/IEC 

Information  Resource  Dictionary  System  (IRDS)  Services 
Interface  Amendment  1 :  C  Language  Binding 

10728  AMD 
1:1994 

Informational 

(Draft) 

3.10.2.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.2.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.2.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.2.3.5  Related  standards.  DOD  5200.28-STD,  26  December  1995,  DOD  Trusted  Computer 
Systems  Evaluation  Criteria,  is  related  to  NCSC-TG-021.  The  following  specifications  are  related 
to  DOD  5200.28-STD: 

a.  NCSC-TG-018,  Version  1,  July  1992,  A  Guide  to  Understanding  Object  Reuse  in 
Trusted  Systems 
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b.  NCSC-TG-025,  Version  2,  September  1991,  A  Guide  to  Understanding  Data 
Remnants  in  Automated  Information  Systems 

3.10.2.3.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.10.2.4  Network  security  architecture.  (This  BSA  appears  in  both  part  7  and  part  10.)  OSI 
security  architecture  defines  the  general  security-related  architectural  elements,  provides  a  general 
description  of  security  services  and  related  mechanisms,  and  defines  the  positions  within  the  OSI 
Reference  Model  at  which  the  services  and  mechanisms  may  be  provided.  Open  systems  security 
frameworks  address  data  elements  and  sequences  of  operations  that  are  used  to  obtain  security 
services. 

Note:  The  security  architecture  and  framework  standards  are  intended  to  provide  guidance  and 
background  information  to  developers.  In  general,  these  standards  do  not  provide  implementable 
specifications  against  which  conformance  can  be  claimed. 

3.104.4.1  Standards.  Table  3. 10-4  presents  standards  for  network  security  architecture. 


TABLE  3.104  Network  security  architecture  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Network  interpretation 

NCSC-TG-005, 
Version  1: 1987 

Mandated 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2;  Security  Architecture 
(same  as  CCHT  X.800: 1991) 

7498-2:1989 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Systems  •  Part  2: 
Authentication  Framework 

10181-2:1996 

Informational 

(Approved) 

IPC 

ISO 

OSI  Upper  Layer  Security  Model 

10745:1993 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1 :  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Lower  Layer  Security  Model 

TR  13594:1995 

Informational 

(Approved) 

CPC 

IBTF 

Security  Architecture  fo r  the  Internet  Protocol 

RFC  1825: 1995 

Emerging 

(Draft) 

CPC 

IETF 

Security  Architecture  for  the  Internet  Protocol 

draft-ietf-iptiec' 
arch-sec-0  l.Ut,  10 
November  1996 

Informational 

(Draft) 

NPC 

IEEE 

Standard  for  Interoperable  LAN  Security  -  Part  A:  The 
Model 

802.10a:  1989 

Emerging  1 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Systems,  Part  I : 
Overview 

10181-1 

Informational  M 
(Draft)  | 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Part  3:  Access 
Control 

10181-3 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Part  4:  Non- 
Repudiation  (samedi  ITU-TS  X.8I3) 

10181-4 

Informational  [ 
(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  System*,  Part  5: 
Confidentiality 

10181-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Part  6: 
Integrity  (aame  as  ITU-TS  X.815) 

10181-6 

Informational 

(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

tPC 

ISO/IEC 

OS I  Security  Framework!  for  Open  Syatenu,  Part  7: 
Security  Audit  Framework 

10181-7 

Informational 

(Draft) 

IPC 

ISO/1EC 

OSI  Security  Framework*  for  Open  Syitems  Part  8:  Key 
Management 

10181-8 

informational 

(Draft) 

3.10.2.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.2.4.3  Standards  deficiencies.  The  Upper  Layer  Security  Model  (ISO  10745)  primarily 
addresses  FTAM  requirements  and  does  not  deal  with  Directory,  Transaction  Processing,  and 
X.400. 

3.10.2.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.10.2.4.5  Related  standards.  NCSC-TG-011,  Version  1, 1  August  1990,  Trusted  Network 
Interpretation  Environments  Guideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation  is  a  guideline  supporting  the  TCSEC. 

3.10.2.4.6  Recommendations.  The  standards  listed  as  mandated  are  recommended. 
Implementations  involving  security  services  should  require  conformance  to  the  security  principles 
and  concepts  of  the  DGSA  (TAFIM,  Volume  6)  and  supporting  standards.  RFC  1825  is  an 
emerging  standard  that  provides  the  current  view  of  how  to  implement  security  functions  within 
an  Internet  Protocol  (IP)  suite  network.  The  Internet  Draft  document  draft-ietf-ipscc-arch-sec- 

0 1  .txt  is  a  "work-in-progress"  revision  of  RFC  1 825. 
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3.10.23  Operating  system  security.  (This  BSA  appears  in  both  part  8  and  part  10.)  Operating 
system  security  services  provide  basic  reference  monitor  services.  These  security  mechanisms 
control  the  flow  of  data  and  use  of  applications  to  ensure  the  system  security  policy  is  adhered  to. 

3.1023.1  Standards.  Table  3.10-5  presents  standards  for  operating  system  security. 


TABLE  3.10-5  Operating  system  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Syi  terns  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Password  Usage 

FIPS  PUB  112: 
1985 

Mandated 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(tame  as  CCITT  X. 800. 1991) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  on  Evaluation  of  Technique*  for  Automated 
Personal  Identification 

FIPS  PUB  48:1977 

Informational 

(Approved) 

IPC 

ISO/tEC 

OSI  Syitemt  Management,  Part  7:  Security  Alarm 
Repotting  Function  (tame  a*  ITU-T  X.736) 

10164-7:1992 

Informational 

(Approved) 

NPC 

IEKF. 

POSIX,  Part  hSyrtem  API  •  Amendment  n:  Protection, 
Audit,  and  Control  Interface*  (C  Language),  Draft  15 

Pl003.le:  1995 

Emerging 

(Draft) 

NPC 

IFFF 

POSIX  Part  2:  Shell  and  Utilities  •  Amendment  n: 
Protection  and  Control  Utilitiet,  Draft  15 

P1003.2c:  1995 

Emerging 

(Draft) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Vertion  1.0: 
1996 

Emerging 

(Draft) 

NPC 

IEEE 

Guide  to  the  POSIX  Open  Syitemt  Environment  -  A 
Security  Framework 

P1003.22:  1995 

Informational 

(Draft) 

NPC 

SAE 

Avionic*  Operating  Syitem  API  Requirements  for  the 
Society  of  Automotive  Engineers 

ARD  50067:  1996 

Informational 

(Draft) 

NPC 

1BEF- 

Portable  Operating  System  (POSIX),  Part  1;  Syitem  API/C 
Language  (same  as  ISO  9945- 1 : 1990) 

1003.1:1990 

Informational  1 
(Superseded)  j 

3.10.23.2  Alternative  specifications.  No  alternative  specifications  are  available. 

3.10.2.5.3  Standards  deficiencies.  General  operating  systems  for  personal  computers  are 
inherently  insecure  and  should  not  be  used  in  DOD  acquisitions  without  an  assurance  of  "add-on" 
security  features  and  an  approved  security  risk  analysis  providing  at  least  a  C2  level  of  trust  per 
DOD  Directive  5200.28. 

The  DGSA  stresses  the  need  for  separation  mechanisms,  such  as  a  separation  kernel,  to  maintain 
strict  isolation,  that  is,  information  domains  must  be  completely  isolated  from  each  other.  The 
DGSA  concept  requires  that  information  transfers  between  domains  may  occur  if,  and  only  if,  a 
relationship  is  explicitly  defined  in  each  information  domain's  security  policy.  There  are  no  current 
or  emerging  standards  for  design  and  implementation  of  separation  kernels  nor  for  programming 
interfaces  for  separation  kernels. 
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Due  to  its  age,  FIPS  48  does  not  include  information  on  modem  security  concepts. 

3.10 .2.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.2.5.5  Related  standards.  ISO/IEC  9945-1  as  profiled  by  FIPS  151-2  is  related  to  IEEE 
P1003.1e  and  IEEE  P1003.2c. 

The  following  Compartmented  Mode  Workstation  (CMW)  specifications  are  related  to  operating 
system  security: 

a.  DDS-2600-5502-87,  Security  Requirements  for  System  High  and  Compartmented 
Mode  Workstations 

b.  DDS-2600-6243-92,  Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

c.  DDS-2600-62 16-91,  Compartmented  Mode  Workstation  (CMW)  Labeling: 
Encoding  Format 

d.  DDS-2600-6243-9 1 ,  Compartmented  Mode  Workstation  (CMW)  Labeling: 
Source  Code  and  User  Interface  Guidelines,  Revision  1 

3.10.2.5.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.10.3  System  management  System  management  encompasses  those  security  functions 
required  to  maintain  an  operationally  secure  system.  This  area  includes  analysis  areas  such  as 
certification  and  accreditation  and  risk  management,  as  well  as  operationally  motivated  concerns 
such  as  alarm  reporting,  audit,  and  cryptographic  key  management 

3.10.3.1  Certification  and  accreditation.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 
Certification  and  accreditation  constitute  a  set  of  procedures  and  judgments  leading  to  a 
determination  of  the  suitability  of  the  system  to  operate  in  the  targeted  operational  environment 

Accreditation  is  the  official  management  authorization  to  operate  a  system.  The  accreditation 
normally  grants  approval  for  the  system  to  operate  (a)  in  a  particular  security  mode,  (b)  with  a 
prescribed  set  of  countermeasures  (administrative,  physical,  personnel,  communications  security, 
emissions,  and  computer  security  controls),  (c)  against  a  defined  threat  and  with  stated 
vulnerabilities  and  countermeasures,  (d)  within  a  given  operational  concept  and  environment,  (e) 
with  stated  interconnections  to  other  systems,  (f)  at  an  acceptable  level  of  risk  for  which  the 
accrediting  authority  has  formally  assumed  responsibility,  and  (g)  for  a  specified  period  of  time. 
The  Designated  Approving  Authority(s)  (DAA)  formally  accepts  security  responsibility  for  the 
operation  of  the  system  and  officially  declares  that  the  specified  system  will  adequately  protect 
against  compromise,  destruction,  or  unauthorized  modification  under  stated  parameters  of  the 
accreditation.  The  accreditation  decision  affixes  security  responsibility  with  the  DAA  and  shows 
that  due  care  has  been  taken  for  security  in  accordance  with  the  applicable  policies. 

An  accreditation  decision  is  in  effect  after  the  issuance  of  a  formal,  dated  statement  of 
accreditation  signed  by  the  DAA,  and  remains  in  effect  for  the  specified  period  of  time  (varies 
according  to  applicable  policies).  A  system  processing  classified  or  sensitive  unclassified 
information  should  be  accredited  prior  to  operation  or  testing  with  live  data  unless  a  written 
waiver  is  granted  by  the  DAA.  In  some  cases  (e.g„  when  dealing  with  new  technology,  during  a 
transition  phase,  or  when  additional  time  is  needed  for  more  rigorous  testing),  the  DAA  may  grant 
an  interim  approval  to  operate  for  a  specified  period  of  time.  At  the  end  of  the  specified  time 
period,  the  DAA  must  make  the  final  accreditation  decision. 

Certification  is  conducted  in  support  of  the  accreditation  process.  It  is  the  comprehensive  analysis 
of  both  the  technical  and  nontechnical  security  features  and  other  safeguards  of  a  system  to 
establish  the  extent  to  which  a  particular  system  meets  the  security  requirements  for  its  mission 
and  operational  environment.  A  complete  system  certification  must  consider  factors  dealing  with 
the  system  in  its  .nique  environment,  such  as  its  proposed  security  mode  of  operation,  specific 
users,  applications,  data  sensitivity,  system  configuration,  site/facility  location,  and 
interconnections  with  other  systems.  Certification  should  be  done  by  personnel  who  are 
technically  competent  to  assess  the  systems  ability  to  meet  the  security  requirements  according  to 
an  acceptable  methodology.  The  resulting  documentation  of  the  certification  activities  is  provided 
to  the  DAA  to  support  the  accreditation  decision.  Many  security  activities  support  certification, 
such  as  risk  analysis,  security  test  and  evaluation,  and  various  types  of  evaluations. 

Ideally,  certification  and  accreditation  procedures  encompass  the  entire  life  cy  i  of  the  system. 
Ideally,  the  DAA  is  involved  from  the  inception  of  the  system  to  ensure  that  the  accreditation 
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goals  are  clearly  defined.  A  successful  certification  effort  implies  that  system  security  attributes 
were  measured  and  tested  against  the  threats  of  the  intended  operational  scenarios.  Additionally, 
certification  and  accreditation  are  seen  as  continuing  and  dynamic  processes;  the  security  state  of 
the  system  needs  to  be  tracked  and  assessed  through  changes  to  the  system  and  its  operational 
environment.  Likewise,  the  management  decision  to  accept  the  changing  system  for  continued 
operation  is  an  ongoing  decision  process. 

Standards  for  certification  and  accreditation  services  provide  definitions  and  procedures  for  the 
testing  and  accreditation  of  computer  systems  in  so  far  as  their  conformance  with  security 
standards  is  concerned. 

3.10.3.1.1  Standards.  Table  3.10-6  presents  standards  for  certification  and  accreditation. 


TABLE  3.10-6  Certification  and  accreditation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

dod 

The  DOD  Tniated  Computer  Syitemi  Evaluation  Criteria 

DOD  5200.28* 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guideline  for  Computer  Security  Certification  and 
Accreditation 

PIPS  PUB 
102:1983 

Informational 

(Approved) 

IPC 

CCBB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venlon  1.0 

CC  Vernon  1.0: 
19% 

Emerging 

(Draft) 

GPC 

dod 

DOD  Information  Technology  Certification  and 
Accreditation  Proceu 

DITSCAP:  1996 

Informational 

(Draft) 

3.10.3.1.2  Alternative  specifications.  No  other  consortia  or  de  facto  specifications  are  available. 

3.10.3.1.3  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  102  does  not  include  services 
for  the  certification  and  accreditation  of  all  modem  security  concepts. 

Certification  and  accreditation  evaluation  criteria  that  address  current  information  technology, 
such  as  distributed  computing  and  networking,  are  needed.  As  new  criteria  such  as  the  Common 
Criteria  emerge,  revision  of  existing  certification  and  accreditation  guidelines  may  be  required. 

3.10.3.1.4  Portability  caveats.  There  are  no  portability  problems  related  to  the  existing 
specifications. 

3.10.3.1.5  Related  standards.  NCSC-TG-029,  "Introduction  to  Certification  and  Accreditation," 
January  1994,  discusses  basic  concepts  related  to  certification  and  accreditation  and  is  the  first  of 
a  series  of  guidelines  in  the  "Rainbow  Series'1  supporting  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC)  standard. 

3.10.3.1.6  Recommendations.  The  mandated  standard  is  recommended. 
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Procurements  that  require  that  an  A1S  be  certified  and/or  accredited  must  reference  DOD 
Directive  3200.28  and  applicable  designated  approving  authority  guidance.  DOD  Directive 
3200.28,  "Security  Requirements  for  Automated  Information  Systems  (AISs),"  requires 
certification  and  accreditation  of  AIS.  FIPS  PUB  102,  Guidelines  for  Computer  Security  and 
Accreditation  provides  Federal  guidelines  for  certification  and  accreditation.  Because  of  its  age, 
this  FIPS  PUB  does  not  include  services  for  the  certification  and  accreditation  of  all  modem 
security  concepts.  DOD  5200.28-STD  provides  criteria  to  assess  security  assurances  of  trusted 
systems  to  specific  classes.  DCID  1/16  provides  security  requirements  for  systems  processing 
intelligence  information. 

The  DISA  CISS  and  NSA  are  each  developing  documents  that  will  standardize  the  certification 
and  accreditation  process  within  DOD.  Each  document  is  in  draft  form;  final  documents  are 
expected  to  be  issued  in  1997.  The  NSA  document,  "Certification  and  Accreditation  Process 
Handbook  for  Certifiers,"  will  be  published  as  a  "Rainbow”  series  document  supporting  the 
TCSEC  standard.  This  NSA  handbook  focuses  on  certification  and  accreditation  of  standalone 
systems.  The  DISA  CISS  document,  "DOD  Information  Technology  Certification  and 
Accreditation  Process"  (DITSCAP),  will  be  published  as  a  DOD  publication.  The  DITSCAP 
focuses  on  certification  and  accreditation  in  conjunction  with  the  programmatic  aspects  of  the 
DII. 
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3.10.34  Security  risk  management.  (This  BSA  appears  in  part  2,  part  7,  part  9,  and  pan  10.) 
Security  risk  management  supports  accreditation  through  a  risk  analysis  of  an  information  system 
and  its  operational  environment,  and  the  steps  taken  to  manage  the  risk  requirements. 

3.1044.1  Standards.  Table  3.10-7  presents  standards  for  security  risk  management 


TABLE  3.10-7  Security  risk  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ili 

OPC 

DOD 

The  DOD  Traded  Computer  Syatema  Evaluation  Criteria 

DOD  5200.28* 
STD:  1985 

Mandated 

(Approved) 

GPC 

NIST 

Guideline  for  the  Anatyrii  of  Local  Are*  Network  Security 

PIPS  PUB 
191:1994 

Informational 

(Approved) 

OPC 

NIST 

Guideline  for  Automated  Data  ProctMini  Riik  Analyu* 

PIPS  PUB  65:1979 

Infoimational 

(Approved) 

OPC 

NIST 

Guideline*  for  Automatic  Data  Proceuing  Physical 
Security  and  Riik  Management 

FIPS  PUB  31:1974 

Infoimational 

(Approved) 

3.10.344  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.344  Standards  deficiencies.  Because  of  its  age,  FIPS  PUB  31  does  not  include 
information  about  modem  security  concepts. 

3.1044.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.1044.5  Related  standards.  The  following  standards  are  related  to  the  TCSEC  standard: 

a.  CSC-STD-003-85  25  June  1985,  Computer  Security  Requirements  -  Guidance  for 
Applying  the  Department  of  Defense  Trusted  Computer  Security  Evaluation 
Criteria  in  Specific  Environments 

b.  CSC-STD-004-85,  25  June  1985,  Technical  Rationale  Behind  CSC-STD-003-85: 
Computer  Security  Requirements  -  Guidance  for  Applying  the  Department  of 
Defense  Trusted  Computer  Security  Evaluation  Criteria  in  Specific  Environments 


3.10.34.6  Recommendations.  The  mandated  standard  is  recommended.  Office  of  Management 
and  Budget  (OMB)  Circular  A- 130,  "Management  of  Federal  Information  Resources,"  provides 
guidance  on  effective  security  risk  management  of  federal  information  systems.  NIST  Special 
Publication  800-12,  "An  Introduction  to  Computer  Security:  The  NIST  Handbook"  provides 
additional  guidance  on  risk  management  DOD  Directive  5200.28  requires  a  risk  analysis  of  an 
information  system  be  conducted  in  its  operational  environment  to  support  accreditation  of  the 
information  system.  System  implementors  should  perform  the  risk  analysis  in  accordance  with 
CSC-STD-003-85  and  CSC-STD-004-85  to  determine  the  appropriate  DOD-5200.28-STD  class. 
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3.10.3.3  Security  management  (This  BSA  appears  in  part  7,  part  8,  part  9,  and  part  10.) 
Security  management  is  a  particular  instance  of  information  system  management  Security 
management  provides  supporting  services  that  contribute  to  the  protection  of  information  and 
resources  in  open  systems  in  accordance  with  information  domain  and  information  security 
policies.  The  basic  elements  that  must  be  managed  are  users,  security  policies,  information, 
information  processing  systems  that  support  one  or  more  security  policies,  and  the  security 
functions  that  support  the  security  mechanisms  (automated,  physical,  personnel,  or  procedural) 
used  to  implement  security  services.  For  each  of  these  elements,  the  managed  objects  that 
constitute  them  must  be  identified  and  maintained.  For  example,  users  must  be  known  and 
registered,  security  policies  must  be  represented  and  maintained  and  information  objects  must  be 
identified  and  maintained.  Security  policies,  security  services  and  security  mechanisms  are  the  first 
classes  of  managed  objects. 


3.10.3.3.1  Standards.  Table  3.10-8  presents  standards  for  security  management 


TABLE  3.10-8  Security  management  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trotted  Computer Sy items  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trotted  Networic  Interpretation 

NCSC-TG-005, 
Version  1:  1987 

Mandated 

(Approved) 

GPC 

DOD 

Trotted  Databeie  Management  Syatem  Interpretation  of  the 
Trotted  Computer  Syttemt  Evaluation  Criteria 

NCSC-TG-021, 
Version  1:  1991 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Seivicea 

DCE  i.l  Security 
Service*:  1994 

Mandated 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedure*  for  Dittribuled  Operation  (X- 
ref:  ISO  9594-4) 

X.5I8: 1993 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCBRev. 

1.2.2:1996 

Infoimational 

(Approved) 

IPC 

ISO/tEC 

OSI  Common  Management  Information  Service*  (CM1S) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:1992 

Infoimational 

(Approved) 

IPC 

iso/ffic 

Information  Technology  -  Open  Syttem*  Interconnection  - 
Common  Management  Information  Protocol  (CMIP)  -  Part 
I:  Specification  (Includes  amendment  1  and  2  of  ISO/IEC 
9596-1:1990) 

9596-1:1991 

Informational 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopts  ISO  Profile  Set*  1 1 183-X,  12059- 
X,  and  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Infoimational 

(Approved) 

IPC 

1SO/IEC 

OSI  Systems  Management,  Part  7:  Security  Alarm 
Reporting  Function  (time  as  ITU-T X.736) 

10164-7:1992 

Infoimational 

(Approved) 

IPC 

ISO/1EC 

OSI  Syttem*  Management,  Part  8:  Security  Audit  Trail 
Function  (tame  u  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Sy*tem*  Management,  Part  9:  Object*  and  Attribute* 
for  Accen  Control 

10164-9:1995 

Infoimational 

(Approved) 

IPC 

ISO 

OSI  Basic  Reference  Model,  Part  2:  Security  Architecture 
(same  aaCCl'IT  X.800:I991) 

7498-2:1989 

Infoimational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

IEEE 

PQSIX  Put  2:  Shell  and  Utilities  -  Amendment  n: 
Protection  end  Control  Utilities,  Draft  IS 

P1003.2c:  1995 

Emerging 

(Draft) 

NPC 

IFPK 

PQSIX,  Pert  LSyrtem  API*  Amendment  a:  Protection, 
Audit,  end  Control  Interface*  (C  Language),  Draft  IS 

P1003.U:  1995 

Emerging 

(Draft) 

CPC 

OMG 

Common  Object  Request  Broker  Architecture  (CORBA) 
Security 

OMG  95*  12-1: 
1995 

Emerging 

(Draft) 

CPC 

IETF 

Domain  Name  Syitem  (DNS)  Security  Extension* 

RFC  2065:1997 

Emerging 

(Draft) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Informational 

(Superseded) 

NPC 

IFFF 

Standard  for  Interoperable  LAN  Security  -  Part  D:  Security 
Management 

802.  lOd 

Informational 

(Formative) 

IK' 

ISO/IEC 

Management  Plan  for  Security 

JTC1/SC21  SD*7 

Informational 

(Draft) 

3.10.33.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.3.33  Standards  deficiencies.  Deficiencies  exist  in  standardization  of  security  policy  rule 
representation;  key  management,  including  generation,  distribution,  and  accounting;  audit 
information  formats;  exchange  of  security  management  information;  and  remote  security 
management 

The  DGSA  principle  of  decision  and  enforcement  separation  requires  that  the  functions 
determining  how  to  enforce  a  security  policy  and  the  actual  enforcement  of  the  policy  be 
implemented  independently.  That  is,  the  enforcement  mechanisms  do  not  need  any  knowledge  of 
security  policy.  Standards  are  needed  for  object  class  definitions  for  classes  of  managed  objects 
and  for  methods  of  representing  security  policy. 

The  DGSA  calls  for  a  separation  mechanism,  such  as  separation  kernel,  to  mediate  all  calls  to 
security  critical  functions  to  ensure  that  strict  isolation  is  maintained.  Standardization  of  object 
class  definitions  for  management  of  critical  functions  used  within  the  separation  kernel  is  needed. 

The  present  1SO/IEC  10164-7  "Security  Alarm  Reporting  Function,"  and  10164-8,  "Security 
Audit  Trail  Function,"  standards  were  designed  with  network  security  in  mind.  Little  work  has 
been  done,  either  in  standards  groups  or  in  products,  on  how  to  use  these  standards  for  general 
system  management  (e.g.,  computer  systems  and  software). 

FIPS  PUB  179-1  supersedes  FIPS  PUB  179,  The  present  GNMP  specifications  require  ISO 
CMIS/CMIP  to  communicate  management  information  and  ISO  OSI  networking  protocols. 
Plans  are  for  the  GNMP  eventually  to  provide  a  capability  to  integrate  the  present  GNMP  with 
SNMP.  One  reason  for  this  goal  is  the  widespread  use  of  SNMP. 

No  Ada  bindings  exist  for  any  of  the  ISO  or  consortia  system  management  specifications. 
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The  IEEE  POSIX  Security  Working  Group  (formerly  P1003.6)  is  defining  security  extensions  to 
the  base  POSIX  interface  standard  (ISO  9945-1),  to  include  support  for  audit,  privilege, 
discretionary  and  mandatory  access  control,  and  information  labels.  These  have  been 
redesignated  IEEE  P1003.  le  and  IEEE  P1003.2c.  The  draft  standards  are  still  incomplete,  and 
the  specifications  may  change. 

The  POSIX/UNIX  permission  bits  are  inadequate  for  fine-grained  control  over  exactly  which 
users  can  perform  specified  actions  to  particular  files. 

In  the  IETF,  efforts  to  develop  an  acceptable  security  standard  for  SNMPv2  have  been  on  hold 
since  September  1995  when  the  IETF  SNMP  Working  Group  failed  to  agree  on  the  proposals 
submitted.  Since  then,  two  sets  of  proposals  for  providing  SNMPv2  security  have  emerged.  The 
first  set  of  proposed  specifications,  the  User-based  Security  Model  (USEC),  also  referred  to  as 
SNMPv2u,  consists  of  two  documents:  RFC  1909,  "An  Administrative  Infrastructure  for 
SNMPv2"  and  RFC  1910,  "The  User-based  Security  Model  for  SNMPv2."  Both  RFCs  were 
issued  28  February  1996  and  are  classified  by  the  IETF  as  experimental  RFCs.  The  other 
proposal  is  known  as  SNMPv2*,  which  its  proponents  claim  is  heavily  based  on  USEC.  Neither 
USEC  nor  SNMPv2*  has  been  approved  for  a  standards  track  by  IETF. 

3.10.3.3.4  Portability  caveats.  The  structure  of  certain  traditional  UNIX  directories,  such  as  the 
familiar  "/tmp,"  "/usr/spool,"  and  "/usr/spool/mail"  directories  must  be  expressly  managed  to 
accommodate  the  P1003.  le  and  P1003.2c  security  stand  ’  •.  This  is  because  these  are 
directories  to  which  all  users  have  access  and  to  which  many  programs  write.  A  change  in  the 
way  programs  write  to  directories  has  the  potential  for  causing  software  portability  and  systems 
administrator  portability  problems. 

The  traditional  UNIX  permission  bits  that  have  been  carried  into  POSIX  are  inadequate  for 
defining  exactly  which  user  can  perform  specific  actions  on  specific  files.  Eliminating  the 
permission  bits  in  favor  of  Access  Control  Lists  could  make  the  secure  POSIX  systems 
incompatible  with  non-POSIX  compliant  systems  and  many  applications. 

OSF  DCE  Version  1.1 's  authentication  service  is  based  on  Kerberos  Version  5  (RFC  1510),  but  is 
not  totally  compatible  wth  RFC  1510.  DCE  1 .2.2  adds  testing  and  official  support  for  Kerberos 
Version  5. 

3.10.3.3.5  Related  standards.  1SO/IEC  9945-1  as  profiled  by  FIPS  PUB  151-2  is  related  to 
IEEE  P1003.  le  and  IEEE  P1003.2c. 

3.10.3.3.6  Recommendations.  The  mandated  standards  are  recommended. 

All  IEEE  P1003.  le  and  IEEE  P1003.2c  security  systems  should  incorporate  Access  Control  Lists 
as  an  optional  feature  in  addition  to  permission  bits  (not  "in  place  of  permission  bits).  The 
incompatibilities  between  the  two  access  control  methods  (permission  bits  and  access  control 
lists)  are  not  resolvable.  The  best  method  for  resolving  the  overall  problems  seem  to  be 
incorporation  Access  Control  Lists  as  an  optional  feature  on  top  of  permission  bits.  The 
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permission  bits  would  represent  the  lowest  common  denominator  of  security,  showing  the 
maximum  amount  of  openness  possible  in  a  system.  Organizations  needing  only  the  lowest  level 
of  security  could  continue  to  use  the  familiar  permission  bits  and  associated  "chmod"  command. 
Use  of  access  control  lists  will  require  a  change  in  security  policy  such  that  access  is  granted  if 
and  only  if  permission  is  granted  and  access  control  permits  it 
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3.10.3.4  Security  association  and  key  management  (This  BSA  appears  in  part  7,  part  9,  and 
part  10.)  A  security  association  is  the  totality  of  communication  and  security  mechanisms  and 
functions  (e.g.,  communications  protocols,  security  protocols,  doctrinal  mechanisms,  security- 
critical  mechanisms  and  functions)  that  securely  binds  together  two  security  contexts  in  different 
end  systems  or  relay  systems  supporting  the  same  information  domain.  A  security  association  is  an 
application  association  that  includes  additional  support  from  security  functions  and  mechanisms. 
Key  management  provides  procedures  for  handling  cryptographic  keying  material  to  be  used  in 
symmetric  or  asymmetric  cryptographic  mechanisms.  It  includes  key  generation,  key  distribution, 
key  storage,  key  archiving,  and  key  deletion. 

3.10.3.4.1  Standards.  Table  3.10-9  presents  standards  for  security  association  and  key 
management 


TABLE  3.10-9  Secu>  .ly  association  and  key  management  standards 


Standard 

Type 

Sponsor 

Standard 

Stan  ■*«•<{ 
Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NSA 

Key  Exchange  Algorithm 

R21 -TECH  *23-94: 
1994 

Mandated 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Key  Management 
Protocol  (KMP) 

SDN.903,  Version 
3.2:  1989 

Mandated 

(Approved) 

GPC 

NIST 

Key  Management  Using  ANSI  X9.17 

FIPS  PUB 
171:1992 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

11586-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  3:  Security 
Exchange  Service  Element  Protocol  Specification 

11586-3:1994 

Informational 

(Approved) 

IPC 

ISO 

Banking  Key  Management  (wholesale) 

8732:1988 

Infownationai  jj 
(Approved)  | 

NPC 

ANSI 

Financial  Institution  Key  Management  (wholesale) 

X9.17-1991 

Informational  1 
(Approved)  I 

NPC 

IEEE 

Standard  for  InteroperoWe  IAN  Security  -  Part  C:  Key 
Management  Protocol  (KMP) 

802.10c 

Emerging  jj 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Systems  Part  8:  Key 
Management 

10181-8 

Informational  1 

(Draft)  ] 

CPC 

IETF 

Internet  Security  Association  and  Key  Management 
Protocol  (1SAKMP) 

drafl-ietf-ip«ec- 

isalunp-07.lxl,.p*. 

21  February  1997 

Infotmational 

(Draft) 

CPC 

IETF 

The  Photuris  Session  Key  Management  Protocol 

draft-simpson- 
photuris-ll.txt,  13 
June  19% 

Informational 

(Draft) 

CPC 

IETF 

Simple  Key  Management  for  Internet  Protocols  (SKIP) 

draft  •  ietf- y«sec- 

skip-07.txt.  August 
1996 

Informational 

(Draft! 

CPC 

IETF 

The  Oakley  Key  Determination  Protocol 

draft-ietf-ipsc- 

oaldey-01.txt. 

5/10/96 

Informational 

(Draft) 

NPC 

IEEE 

Standard  for  Public- Key  Cryptography 

PI363 

Informational  U 
(Formative)  | 
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3.10.3.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10J.4.3  Standards  deficiencies.  There  is  a  lack  of  guidance  for  establishing  a  Public  Key 
Infrastructure  (PKJ)  to  automatically  manage  public  keys  through  the  use  of  public  key 
certificates.  In  April  1994,  NIST,  in  conjunction  with  seven  other  federal  agencies,  completed  a 
study  on  automated  management  of  public  keys  and  associated  public  key  certificates  on  a 
nationwide  basis.  Based  on  the  recommendations  of  the  study,  GSA  Is  establishing  a  PKJ  pilot 
project  to  provide  public  key  certificate  services  for  participating  government  agencies. 

3.10 .3.4.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.10.3.4.5  Related  standards.  There  are  no  related  standards. 

3.10.3.4.6  Recommendations.  The  mandated  standards  are  recommended.  In  FORTEZZA 
applications,  the  NSA-developed  Key  Exchange  Algorithm,  R21  -TECH-23-94,  must  be  used. 

IEEE  P1363,  Standard  for  Public-Key  Cryptography,  is  under  development,  with  the  first  version 
expected  to  be  ready  for  balloting  in  1997. 

The  IETFs  IP  Security  Protocol  (IPSEC)  Working  Group  (WG)  is  developing  an  Internet  Key 
Management  Protocol  (IKMP)  that  will  be  specified  as  an  application  layer  protocol  independent 
of  the  lower  layer  security  protocol.  The  IKMP  will  be  based  on  ISAKMP/Oakley  work  begun  in 
the  Internet  Draft  documents  for  ISAKMP  and  the  Oakley  Key  Determination  Protocol. 
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3,10.3.5  Security  audit  (This  BSA  appears  in  part  7,  part  9,  part  10,  and  part  1 1.)  Security 
auditing  is  a  review  or  examination  of  records  and  activities  to  test  controls,  ensure  compliance 
with  policies  and  procedures,  detect  breaches  in  security,  and  indicate  changes  in  operation 
(paraphrased  from  ISO  7498-2). 

3.10.3.5.1  Standards.  Table  3.10-10  presents  standards  for  security  audit. 


TABLE  3.10-10  Security  audit  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trusted  Computer  Syiterm  Evaluation  Criteria 

DOD  5200,28- 
STD:  1985 

Mandated 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (AdopU  ISO  Profile  Sett  1 1 I83-X,  12059- 
X,  and  12060-X  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

rpc 

iso/mc 

OSI  Syitenu  Management,  Put  8:  Security  Audit  Trail 
Function  (time  u  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approved) 

CPC 

X/Open 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020: 1990 

Informational 

(Approved) 

IPC 

CCBB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CQ  Vertion  1,0 

CC.  Version  1.0: 
1996 

Emerging 

(Draft) 

tPC 

ISO/IEC 

OSI  Security  Frameworiu  for  Open  Syitemi,  Part  7; 
Security  Audit  Framework 

10181-7 

Informational 

(Draft) 

IPC 

ISO/lEC 

OSI  Diuribuied  Transaction  Proceiling  (DTP)  -  Draft 
Amendment!  to  Parti  1-3:  Transaction  Proceiling  Security 

WDAMi  ((SC21 
N6232)  to  ISO 
10026-1.2.3)  1994 

Informational 

(Draft) 

- - - - 1 

3.10.3.5.?,  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.3.5.3  Standards  deficiencies.  ISO  Transaction  Processing  Security  work  (WDAMs  to  ISO 
10026-1,2,3)  is  in  the  early  stages.  Its  content  is  not  defined,  and  it  cannot  be  used  for 
procurement.  ISO  10164-8  does  not  define  a  security  audit,  or  explain  how  to  perform  one.  It 
does  not  define  implementation  aspects,  occasions  where  the  use  of  the  security  audit  trail 
function  is  appropriate,  or  the  services  necessary  for  the  establishment  and  normal  or  abnormal 
release  of  a  management  association. 

There  is  a  need  for  a  standard  for  programming  interfaces  to  support  development  of  portable 
tools  for  audit  trail  analysis  and  configuradon. 

3.10.3.5.4  Portability  caveats.  Proposed  amendments  to  ISO  10026  have  ceased.  This  is  a  high 
portability  risk  area. 

3.10.3.5.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 
a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 
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b.  NCSC-TG-01 1,  Version  1,  1  August  1990,  Trusted  Network  Interpretation 
Environments  Guideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation 

c.  NCSC-TG-001,  Version  2,  June  1988,  A  Guide  to  Understanding  Audit  in  Trusted 
Systems 

3.10.3.5,6  Recommendations.  The  mandated  standard  is  recommended. 
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3.103.6  Security  alarm  reporting.  (This  BSA  appears  in  part  7,  part  9,  part  10,  and  part  11.) 
Security  alarm  reporting  is  die  capability  to  receive  notifications  of  security-related  events,  alerts 
of  any  misoperations  in  security  services  and  mechanisms,  alerts  of  attacks  on  system  security,  and 
information  as  to  the  perceived  severity  of  any  misoperation,  attack,  or  breach  of  security. 

3.103.6.1  Standards.  Table  3.10-1 1  presents  standards  for  security  alarm  reporting. 


TABLE  3.10-11  Security  alarm  reporting  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPoint  1  (Adept*  ISO  Profile  Set*  II183-X,  12059- 
X.  *nd  12060-X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Infoimadotial 

(Approved) 

IYC 

ISO/ffiC 

OS I  Syitem*  Management,  Part  7:  Security  Alarm 
Reporting  Function  (tame  at  ITU-T  X.736) 

10164-7:1992 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 
1:1995 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Informational 
(Super*  eded) 

3.10.3.6.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.3.63  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  ISO  10164-7 
does  not  define  implementation  aspects,  specify  the  manner  )•  which  management  is  accomplished 
by  the  user  of  the  Security  Alarm  Reporting  Function  (SARF),  define  interactions  that  result  in 
the  use  of  the  SARF,  or  specify  the  services  necessary  for  the  establishment  and  normal  and 
abnormal  release  of  a  management  association. 

3.103.6.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.103.63  Related  standards.  There  are  no  related  standards. 

3.10.3.6.6  Recommendations.  There  are  no  recommended  standards  for  security  alarm 
reporting. 
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3.10.4  Authentication.  Authentication  and  identification  objectives  ensure  processes,  systems, 
and  personnel  are  uniquely  identn.id  and  authenticated.  The  granularity  of  identification  must  be 
sufficient  to  determine  the  processes,  system,  and  personnel's  access  rights.  The  authentication 
process  must  provide  an  acceptable  level  of  assurance  as  to  the  professed  identity  of  the 
processes,  systems,  and  personnel. 

3.10.4.1  Personal  authentication.  (This  BSA  appears  in  part  2,  part  3,  part  9,  and  part  10.) 
Personal  authentication  supports  the  accountability  objective  of  being  able  to  trace  all  security 
relevant  events  to  individual  users.  In  addition  to  supporting  unique  identification,  standards  are 
provided  to  authenticate  the  claimed  identity. 

3.10.4.1.1  Standards.  Table  3.10-12  presents  standards  for  personal  authentication. 


TABLE  3.10-12  Personal  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

OPC 

NIST 

Paaswoid  Uuge 

FIPS  PUB  112: 
1985 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

OPC 

NIST 

Guidelines  on  Evaluation  of  Techniques  for  Automated 
Personal  Identification 

FIPS  PUB  48:1977 

Informational 

(Approved) 

IPC 

ISO/ffiC 

Information  Technology  -  Open  Systems  Interconnection  - 
The  Directory:  Authentication  Framework  edition  2  (Same 
as  ITU-T  X, 509: 1993) 

9594-8.2:1993 

Informational 

(Approved) 

OPC 

NIST 

Guideline  for  Use  of  Advanced  Authentication  Technology 
Alternatives 

FTPS  PUB 
190:1994 

Informational 

(Approved) 

CPC 

IETF 

A  One-Time  Password  System 

RFC  1938:  1996 

Emerging 

(Draft) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation.  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

CPC 

IETF 

The  Kerberos  Network  Authentication  Service  (V5) 

RFC  1510:1993 

Informational 

(Draft) 

3.10.4.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.4.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.4.1.4  Portability  caveats.  OSF  DCE  Version  1.1  's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 
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3.10.4.1.5  Related  standards.  The  following  standards  are  related  to  personal  authentication 
standards  (particularly  TCSEC): 

a.  DOD  5200.28-STD,  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

b.  NCSC-TG-017,  Version  1,  "A  Guide  to  Understanding  Identification  and 
Authenticadon  in  Trusted  Systems 

c.  CSC-STD-002-85,  "Password  Management  Guideline" 

d.  NCSC-WA-002-85,  "Personal  Computer  Security  Considerations" 

e.  ITU-T  X.509  (1993)  (same  as  ISO  9594-8),  The  Directory:  Authentication 
Framework 

3.10.4.1.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.10.4.2  Network  authentication.  (This  BSA  appears  in  part  7  and  part  10.)  Network 
authentication  services  establish  the  validity  of  a  claimed  identity  (peer-entity)  or  origin  (data) 
(paraphrased  from  ISO  7498-2). 

3.10.4.2.1  Standards.  Table  3.10-13  presents  standards  for  network  authentication. 


TABLE  3.10-13  Network  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Information  Technology  >  Defease  Standard  tied  Profile* 
AMHXn(D}-  Message  Handling  Sytiems  -  Message 
Security  Protocol  (MSP)  Parts  1-5 

MIL- STD- 2045- 
18500:  1993 

Mandated 

(Approved) 

[PC 

ITU-T 

The  Directory:  Authentication  Framework  (X-ref:  ISO 
9594-8) 

X.509,  Version  3: 
1993 

Mandated 

(Approved) 

CPC 

DOD 

Trotted  Network  Interpretation 

NCSC-TG-005, 
Version  1: 1987 

Mandated 

(Approved) 

GPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

CPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB  180- 

1:1995 

Mandated 

(Approved) 

GPC 

Secure  Data  Network  Syitem  (SDNS)  Security  Protocol  3 
(SP3) 

SDN, 301,  Revision 
1.5: 1989 

Mandated 

(Approved) 

GPC 

DOD 

PORTEZZA  Interface  Control  Document 

FORTEZZA  1CD 
Rev  P1.5: 1994 

Mandated 

(Approved) 

GPC 

DOD 

FORTEZZA  Plus  Interface  Control  Document 

FORTEZZA  Plus 
ICD  Rel  3.0:  1995 

Mandated 

(Approved) 

NPC 

IEEE 

HBHil 

802. 10b:  1992 

Leg»cy 

(Approved) 

GPC 

NSA 

Menage  Security  Protocol  (MSP) 

SDN.701,Rev.  3.0: 
1994 

Legacy 

(Approved)  D 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.70l,v.  4.0. 
Rev.  A:  1997 

Emerging 

(Approved) 

IPC 

ISO 

Information  Processing  Syalema  -  Open  Systems 
Interconnection  -  Service  Definition  for  the  Asaociation 
Control  Service  Element  (ACSE),  Revised  Edition 

8649:1992 
(Incorporates  AM 
1*2) 

Informational 

(Approved) 

—  -  .. 

[PC 

ISO 

Information  Processing  Systems  •  Open  Systems 
Interconnection  -  Protocol  Specification  for  the  ACSE, 
Revised  Edition 

8650:1992 
(Incorporates  AM 

1) 

Informational 

(Approved) 

[PC 

ISO 

Generic  Upper  Layer  Security  (GULS)  •  Part  1 :  Overview. 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS) .  Part  2 [Security 
Exchange  Service  Element  Definition 

11586-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  3:  Security 
Exchange  Service  Element  Protocol  Specification 

11586-3:1994 

Informational 

(Approved) 

[PC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  4:  Protecting 
Transfer  Syntax  Specification 

11586-4:1994 

Informational 

(Approved) 

IPC 

ISO 

Transport  Layer  Security  Protocol  (TLSP)  (Includes 
Amendment  1) 

10736:1994 

Informational 

(Approved) 

[PC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Refrr-nce 

H’^|: 

IPC 

1SO/IEC 

OSI  Security  Frameworks  for  Open  Systems  •  Part  2: 
Authentication  Framework 

10111-2:1996 

fafbiautionai 

(Approved) 

GPC 

NIST 

FIPS  PUB  179- 
1:1993 

Informational 

(Approved) 

GPC 

NSA 

Secure  Del*  Network  Sydem  (SDNS)  Security  Protocol  4 
(SP4) 

SDN.401.Rev. 

1. 3: 19*9 

Informational 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP)  with  MIME 

SDN.704.  Rev.  1.4: 
1996 

Informational 

(Approved) 

CPC 

IETF 

Privacy  Enhancement  for  Internet  Electronic  Mail 

Informational 

(Draft) 

CPC 

IETF 

The  Secure  Socket*  Layer  (SSL)  Protocol  Version  3.0 

draft- ietf-tli- sil¬ 
vers  ion  3-OO.txl,  18 
November  1996 

Emerging 

(Draft) 

CPC 

IETF 

S/MIMF.  Message  Specification:  PKCS  Security  Services 
for  MIME 

Informational 

(Draft) 

tPC 

ISO 

OSI  File  Transfer,  Access  and  Management  (FTAM)  - 
Parts  1-4:  Amendment  4:  Enhancement  to  FTAM  Security 
Services 

8571-1.2.3,4:1988/ 

WDAM4:1993 

Informational 

(Draft) 

GPC 

NSA 

Use  of  X.509  Certificates 

SDN.706,  Rev.  2.0: 
1997 

Informational 

(Draft) 

GPC 

NSA 

X.509  Certificates  sod  Certification  Revocation  List 
Profiles  and  Certificate  Path  Processing  Rules  for  the 
Multilevel  Information  Systems  Security  Initiative  (MI SSI) 

SDN.706.  Rev.  1.1: 
1996 

Informational 

(Draft) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Informational 

(Superseded) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB 
180:1993 

Informational 

(Superseded) 

3.10.4.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.4.2.3  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  Procurements 
requiring  authentication  in  FTAM  cannot  specify  a  standard  at  this  time.  The  ISO  FTAM  security 
effort  is  in  its  early  stages.  Current  proprietary  FTAM  security  is  based  on  passwords  for 
authentication.  ISO  TP  security  work  is  in  the  early  stages.  Its  content  is  not  defined,  and  it 
cannot  be  used  in  a  procurement. 

3.10.4.2.4  Portability  caveats.  Proposed  security  enhancements  to  FTAM  (WDAM4  to  ISO 
8571)  have  ceased.  This  is  a  high  portability  risk  area. 

3.10.4.2.5  Related  standards.  NCSC-TG-01 1,  Version  1 ,  1  August  1990,  Trusted  Network 
Interpretation  Environments  Guideline  -  Guideline  for  Applying  the  Trusted  Network 
Interpretation,  supports  NCSC-TG-005. 

3.10.4.2.6  Recommendations.  The  mandated  standards  are  recommended. 
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MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,’1  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part.  Allied  requirements.  This  DOD 
Standardized  Profile  (DSP)  standard  will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to 
Allied  Communications  Publication  (ACP)  123  or  ACP  120,  Common  Security  Protocol,  when 
the  revision  to  MSP  is  complete. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

DSS  is  intended  to  specify  general  security  requirements  for  generating  digital  signatures. 
Conformance  to  this  standard  does  not  assure  that  a  particular  implementation  is  secure.  The 
responsible  authority  in  each  Government  agency  or  department  shall  assure  that  an  overall 
implementation  provides  an  acceptable  level  of  security.  DSS  can  be  used  in  electronic  mail, 
electronic  funds  transfer,  electronic  data  interchange,  software  distribution,  data  storage,  and 
other  applications  that  require  data  integrity  assurance  and  data  origin  authentication.  It  uses  the 
Secure  Hash  Algorithm  (SHA)  specified  in  FIPS  PUB  180-1,  which  supersedes  FIPS  PUB  180. 
NIST  is  developing  a  validation  program  to  test  implementations  for  conformance  to  DSS. 

The  following  two  documents  should  be  consulted  for  systems  required  to  interface  with  the 
Defense  Message  System  (DMS): 

a.  FORTEZZA  Interface  Control  Document,  Rev.  1.5, 22  December  1994 

b.  FORTEZZA  Plus  Interface  Control  Document,  Release  3.0,  1  June  1995 

SDN.701,  Rev.3.0,  is  used  with  DMS,  Phase  1.  It  is  for  use  with  legacy  systems  only. 

IEEE  802.10b  is  for  use  with  k  cy  LANs  only. 
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3.10.4 3  Entity  authentication.  (This  BS A  appears  in  part  8,  part  9,  part  10,  and  part  1 1 .) 
Entity  authentication  standards  address  data,  processes,  systems,  and  enterprises. 

3.10.4 .3.1  Standards.  Table  3,10-14  presents  standards  for  entity  authentication. 


TABLE  3.10-14  Entity  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  TOD  Truded  Computer  Systems  Evaluation  Criteria 

DOD  5200.28. 
STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

Diitributed  Computing  Environment  (DCE)  Security 
Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Computer  Data  Authentication 

FIPS  PUB 
113:1985 

Informational 

(Approved) 

GPC 

NIST 

Entity  Authentication  Uling  Public  Key  Cryptography 

FIPS  PUB 
196:1996 

Emerging 

(Approved) 

CPC 

OSF 

Diitributed  Computing  Environment  (DCE)  Rev.  1,2.2 

DCE  Rev, 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

Financial  Transactions  -  Retail  Banking  Security 
Requirements  for  Message  Authentication 

9807 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  -  Part  1:  General  Model 

9798-1:1991 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  -  Pvt  3;  Entity 
Authentication  Using  a  Public  Key  Algorithm 

9798-3:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Use  of  Advanced  Authentication  Technology 
Alternatives 

FIPS  PUB 
190:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  2:  Mechanisms  Using 
Symmetric  Hiciphetment  Algorithms 

9798-2:1994 

Informational  U 
(Approved)  | 

IPC 

ISO 

Entity  Authentication  •  Part  4:  Mechanisms  Using  a 
Cryptographic  Check  Function 

9798-4:1995 

Informational  jj 

(Approved)  | 

CPC 

X/Open 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020:  1990 

Informational  j| 
(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Veriion  1.0: 
1996 

Emerging  11 

(Draft)  | 

CPC 

IETF 

The  Kerberos  Network  Authentication  Service  (V5) 

RFC  1510:1993 

Informational 

(Draft) 

IPC 

ISO 

Entity  Authentication  Mechanisms,  Part  S:  Entity 
Authentication  Using  Zero  Knowledge  Techniques 

9798-5:1993 

Informational 

(Draft) 

3.10.4.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.4.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.4.3.4  Portability  caveats.  OSF  DCE  Version  1.1's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1 5 10),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1 .2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 
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3.10.4.3.5  Related  standards.  The  following  standards  are  related  to  entity  authentication: 

a.  DOD  NCSC-TG-017,  Version  1,  September  1991,  Guide  to  Understanding 
Identification  and  Authentication  in  Trusted  Systems. 

b.  FIPS  PUB  196, 1 1  October  1996. 

FIPS  PUB  196  becomes  effective  6  April  1996.  It  is  based  on  ISO/IEC  9798- 
3:1993  and  specifies  two  challenge-response  protocols  by  which  entities  in  a 
computer  system  may  authenticate  their  identities  to  one  another.  FIPS  PUB  196 
is  for  use  in  public  key  based  challenge-response  and  authentication  systems  at  the 
application  layer  within  computer  and  digital  telecommunications  systems. 

3.10.4.3.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.10.5  Access  control.  Access  control  is  the  prevention  of  unauthorized  use  of  a  resource 
including  its  use  in  an  unauthorized  manner.  The  following  areas  present  standards  which  ensure 
that  information  and  resources  are  accessed  only  by  authorized  processes,  systems,  and  personnel, 
and  are  used  only  for  their  intended  purposes. 

3.10.5.1  System  access  control.  (This  BS A  appears  in  part  4,  part  9,  part  10,  and  part  1 1 .) 
System  access  control  standards  provide  high-level  guidance  on  access  control  frameworks  and 
implementation. 

3.10.5.1.1  Standards.  Table  3.10-15  presents  standards  for  system  access  control. 


TABLE  3.10-15  System  access  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trotted  Computer  System*  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2,2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

mHS&ilSHBl 

7498*2:1989 

Informational 

(Approved) 

tPC 

ISO/IEC 

OSI  Common  Management  Information  Services  (CMIS) 
Definition,  with  Amendment  4:  Access  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  9:  Objects  and  Attributes 

for  Access  Centro. 

10164-9:1995 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems.  Part  3:  Access 
Control 

10181-3 

Informational 

(Draft) 

3.10.5.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.5.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.5.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.5.1.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 

a.  NCSC-TG-003,  Version  1,  September  1987,  A  Guide  to  Understanding 
Discretionary  Access  Control  in  Trusted  Systems 

b.  NCSC-TG-028,  Version  1,  May  1992,  Assessing  Controlled  Access  Protection 
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NCSC-TG-020-A,  August  1989,  Trusted  UNIX  Working  Group  (TRUSIX) 
Rationale  for  Selecting  Access  Control  List  Features  for  the  UNIX  System 


3.10.5.1.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.10.5.2  Network  access  control.  (This  BSA  appears  in  part  7,  part  9,  and  part  10.)  Access 
control  is  the  prevention  of  unauthorized  use  of  a  resource,  including  its  use  in  an  unauthorized 
manner. 

3.10.5.2.1  Standards.  Table  3.10-16  present  standards  for  network  access  control. 


TABLE  3.10-16  Network  access  control  standard 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

rOQ 

DOD 

Information  Technology  -  Defuut  Standardised  Profile* 
AMHXo(D)-  Metuie  Handbag  System  *  Message 
Security  Protocol  (MSP)  Part*  1-5 

MIL-STD-2045- 

18500:  1993 

Mandated 

(Approved) 

GPC 

NSA 

Secure  Data  Network  Syftem  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.  301,  Revision 
1.5: 1989 

Mandated 

(Approved) 

NPC 

TFPF 

Standard  lU  Interoperable  LAN  Security  -  Put  B:  f  toire 
Data  Exchange  (SDL) 

802. 10b:  1992 

Leg*cy 

(Approved) 

IPC 

ISO/IRC 

OSI  Common  Management  Information  Service*  (CMlS; 
Definition,  with  Amendment  4:  Acce*s  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

tPC 

ISO 

T-inipon  Layer  Security  Protocol  (TLSP)  (Include* 
Amencknent  1) 

10736:1994 

Informational 

(Approved) 

IPC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

GPC 

NIST 

Government  Ne.  <ork  Management  Profile  (GNMP) 

FIPS  ,TIB  179- 
1:1995 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  83:1980 

Informational 

(Approved) 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Security  Protocol  4 
/SP4) 

SDN.401,  Rev. 
1.3:1989 

Informational 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701.  v.  4.0, 
Rev.  A:  1997 

Err  urging 
(Approved) 

GPL 

NSA 

Me*sage  Security  Protocol  (MSP) 

SDN.701,  Rev.  3.0: 
1994 

Legacy 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Infoimational 

(Superseded) 

IPC 

ISO/IEC 

Information  Tedwologv  -  Op.  Systems  Interconnection  - 
The  Di«  >iy  -  Part*  1-4  DAM1:  Acceu  Control 

9594- 1 ,2,3,4: 1990/ 
DAM1 

Informational 

(Draft) 

IPC 

ISO/IEC 

Information  Technology  -  Open  System*  Interconnection  - 
The  Directoiy  -  Part  8:  Authentication  Framework,  HAMl : 
Access  Control 

9594-8:199^ 

DAM1 

Informational  1 
(Draft) 

IPC 

ISO 

OS?  File  Transfer,  Access  and  Management  (FT AM)  - 
Puts  1-4:  Amendment  4:  Enhancement  to  FTAM  Security 
Service* 

8571-1,2,3.4:1988/ 

WDAM4:1993 

Informational  1 
(Draft) 

3.10.5.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.5.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown.  FIPS 
P'JB  179-1  supersedes  FIPS  PUB  179. 
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3.10.5.2.4  Portability  caveats.  Proposed  security  enhancements  to  FT  AM  (WDAM4  to  ISO 
857 1 )  has  ceased.  This  is  a  high  portability  risk  area  because  no  standards  exist 

3.10.5.2.5  Related  standards.  NCSC-TG-005,  Version  1.  July  1987,  Trusted  Network 
Interpretation,  and  NCSC-TG-01 1,  Version  1,  August  1990,  Trusted  Networks  Interpretation 
Environments  Guideline  -  Guideline  for  Applying  the  Trusted  Network  Interpretation,  supports 
the  DOD  5200.28-STD. 

3.10.5.2.6  Recommendations.  The  mandated  standards  are  recommended. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5, 1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DOD 
Standardized  Profile  (DSP)  standard  will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP 
123  or  ACP  120,  Common  Security  Protocol,  when  the  revision  to  MSP  is  complete. 

SDN.701,  Rev.3.0,  is  used  with  DMS,  Phase  1.  It  is  for  use  with  legacy  systems  only. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

The  work  on  File  Transfer,  Access,  and  Management  (FTAM)  security  (WDAM4  to  ISO  857 1 ) 
security  enhancements  has  been  suspended.  Procurements  requiring  access  control  for  FTAM  and 
transaction  processing  should  not  use  these  standards. 

IEEE  802. 10b  is  for  use  with  legacy  LANs  only. 
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3.10.6  Confidentiality.  Confidentiality  objectives  ensure  the  protection  of  the  system's  varied 
information  and  resources  from  unauthorized  access.  This  section  provides  open  systems 
standards  guidance  as  well  as  the  specifics  of  cryptography  and  traffic  flow  confidentiality. 

3.10.6.1  Systems  confidentiality.  (This  BSA  appears  in  part  S  and  part  10.)  These  standards 
provide  the  high-level  framework  with  which  to  view  the  security  service  of  confidentiality  in 
systems. 

3.10.6.1.1  Standards.  Table  3.10-17  presents  standards  for  systems  confidentiality. 


TABLE  3.10-17  Systems  confidentiality  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trailed  Computer  Syetemi  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

IPC 

ISO 

OSI  Baik  Reference  Model,  Part  2:  Security  Architecture 
(umeaiCCTTTX.  800: 1991) 

7498-2:1989 

Informational 

(Approved) 

GPC 

NIST 

Computer  Security  Guiddinea  for  Implementing  (he 
Privacy  Act  of!974 

FIPS  PUB  41:1975 

Informational 

(Approved) 

[PC 

CCBB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1.0 

CC  Van  ion  1.0: 
1996 

Emerging 

(Draft) 

IPC 

1SOAF.C 

OSI  Security  Frame  wotfca  in  Opto  Syriemt,  Pari  5: 
Confidentiality 

SHI 

Informational 

(Draft) 

3.10.6.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.6.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.6.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.6.1.5  Related  standards.  DOD  5200.1-R,  "Information  Security  Program  Regulation,"  June 
1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of  DOD 
information.  It  also  contrins  DOD  policy  for  safeguarding  of  classified  information,  including 
accountability,  storage,  transmission,  and  destruction  of  the  information.  DDS-2600-6243-92, 
Compartmented  Mode  Workstation  Evaluation  Criteria,  Version  1  (final),  defines  minimum 
security  requirements  for  workstations  to  be  accredited  in  the  Compartmented  Mode  under  the 
policy  set  forth  in  DCID  1/16.  Public  Law  (PL)  93-579,  Privacy  Act  of  1974,  and  PL  HX1-235, 
Computer  Security  Act  of  1987,  contain  confidentiality  requirements.  FIPS  PUB  41  provides 
guidance  for  conformance  with  PL  93-579. 

3.10.6.1.6  Recommendations.  The  mandated  standard  is  recommended.  The  DGSA,  Volume  6 
of  the  TAF1M,  provides  security  principles  and  target  security  capabilities  to  guide  system 
security  architects  in  creating  specific  security  architectures  consistent  with  ,ie  DGSA.  The 
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DOSA  should  be  used  by  system  security  architects  to  develop  logical  and  specific  security 
architectures. 
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3.10.6 2  Registration  of  cryptographic  techniques.  (This  BSA  appears  in  part  9  and  part  10.' 
These  standards  provide  procedures  for  the  registration  of  cryptographic  algorithms  in  a  standard 
format  with  a  registration  authority.  The  need  for  these  registration  services  is  determined  by  the 
security  architecture  of  the  system  in  question.  These  are  not  irnplementable  specifications  and  no 
conformance  test  is  required. 

J.10.6.2.1  Standards.  Table  3.10-18  presents  standards  for  registration  of  cryptographic 
techniques. 


TABLE  3.10-18  Registration  of  cryptographic  techniques  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Procedure*  for  the  RegiiUation  of  Cryptographic 
Algorithm* 

9979:1991 

Informational 

(Approved) 

3.10.6.2.2  Alternative  specifications.  No  of  cc.i s<i- .  i  c  de  facto  specifications  are  available. 

3.10.6.2.3  Standards  deficiencies.  Deficiencies  in  the  •  "g  standards  are  unknown. 

3.10.6.2.4  Portability  caveats.  Portability  problems  r  .  r.  ••  >  the  existing  specifications  are 
unknown. 

3.10.6.2.5  Related  standards.  No  standards  are  related  to  registration  of  cryptographic 
techniques. 

3.10.6.2.6  Recommendations.  Procurements  requiring  that  all  cryptographic  algorithms  offered 
are  registered  with  a  registration  authority  in  a  standard  format  should  specify  conformance  with 
ISO  9979.  The  NIST  document,  N1STIR  5308,  "General  Procedures  for  Registering  Computer 
Security  Objects,"  December  1993,  describes  the  object-independent  procedures  for  operating  the 
Computer  Security  Objects  Register  (CSOR)  established  by  NIST.  Initially,  the  only  family  of 
objects  registered  in  the  CSOR  is  network  security  labels;  however,  plans  include  adding 
cryptographic  algorithm  modes  of  operation  to  the  CSOR. 
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3.10.6.3  Data  encryption  security.  (This  BS A  appears  in  part  5,  part  7,  part  10,  and  part  1 1 .) 
Encryption  is  the  cryptographic  transformation  of  data  to  produce  cipher  text.  Standards  for  data 
encryption  security  services  describe  services  such  as  definitions/algorithms,  modes  of  operation, 
and  guidelines  for  use  for  those  systems  that  require  their  data  to  be  encrypted  using  data 
encryption  security  services.  None  of  these  standards  are  for  systems  processing  classified 
information. 

3.10.6.3.1  Standards.  Table  3.10-19  presents  standards  for  data  encryption  security. 


TABLE  3.10-19  Data  encryption  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Escrowed  Encryption  Standard  (EES) 

FIPS  PUB  185: 
1994 

Mandated 

(Approved) 

GPC 

NIST 

Data  Encryption  Standard  (DES)  (related  to  ANSI  X3.92- 
1981/R1987/R1993) 

Informational 

(Approved) 

GPC 

NISI 

FIPS  PUB  74:1981 

Infotmational 

(Approved) 

GPC 

NIST 

Data  Encryption  Standard  (DES)  Mode*  of  Operation 
(related  to  ANSI  X3. 106- 1903) 

FIPS  PUB  81:1980 

Informational 

(Approved) 

GPC 

NIST 

Security  Requirement*  fur  Cryptographic  Module* 

FIPS  PUB  140- 
1:1994 

Informational 

(Approved) 

IPC 

ISO 

Mode*  of  Operation  for  a  64-Bit  Block  Cipher  Algorithm 
(Related  to  ANSI  X3. 106) 

8372:1987 

Informational 

(Approved) 

NPC 

ANSI 

Data  Encryption  Algorithm 

X3.  92-1981 
(R1993) 

Informational 

(Approved) 

NPC 

ANSI 

Digital  Encryption  Algorithm  -  Mode*  of  Operation 

X3. 106-1983 
(R1990) 

Informational 

(Approved) 

GPC 

NIST 

Advanced  Encryption  Standard 

FIPS  PUB  JJJ 

Informational 

(Formative) 

3.10.6.3.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary,  for 
example,  RSA. 

3.10.6.3.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.6.3.4  Portability  caveats.  DBS  applications  are  not  interoperable  with  non-DES  systems. 
Portability  problems  related  to  EES  are  Uiiknown.  The  U.S.  controls  export  of  cryptographic 
technologies,  products,  and  related  technologies  as  munitions.  On  October  1 , 1 996,  a  new  federal 
policy  allowing  U.S.  vendors  to  export  products  using  up  to  56-bit  encryption,  provided  the 
vendors  sign  an  agreement  to  make  their  56-bit  encryption  technologies  key-recovery-compliant 
within  24  months, 

3.10.6.3.5  Related  standards.  FIPS  PUB  1 13,  Computer  Data  Authentication,  is  related  to  DES 
security  mechanisms  and  their  standards. 
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3.10.6.3.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  185,  BBS, 
supports  lawful  authorized  access  to  the  keys  required  to  decipher  enciphered  information  for 
systems  requiring  strong  encryption  protection  of  sensitive  but  unclassified  information.  EES 
provides  stronger  protection  than  DES  against  unauthorized  access.  Devices  conforming  to  EES 
may  be  used  when  replacing  Type  n  and  Type  01  (DES)  encryption  devices  owned  by  the 
Government  Implementations  requiring  use  of  EES  should  require  conformance  with  FIPS  PUB 
140-1. 


On  2  January  1997,  NIST  announced  plans  to  develop  a  FIPS,  Advanced  Encryption  Standard, 
incorporating  an  advanced  encryption  algorithm  to  replace  DES  (FIPS  PUB  46-2). 
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3.10.6.4  Traffic  flow  confidentiality.  (This  BSA  appears  in  part  7  and  part  10.)  Traffic  flow 
confidentiality  is  a  service  to  protect  against  unauthorized  traffic  analysis  (ISO  7498-2)  by 
concealing  presence,  absence,  amount,  direction,  and  frequency  of  traffic. 

3.10.6.4.1  Standards.  Table  3.10-20  presents  standards  for  traffic  flow  confidentiality. 


TABLE  3.10-20  Traffic  flow  confidentiality  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NSA 

Secure  Data  Network  System  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.30I,  Revision 
1.5:  1989 

Informational 

(Approved) 

IPC 

ISO 

Netwoik  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

IPC 

ISO 

OS I  Distributed  Transaction  Processing  (DIP)  -  Draft 
Amendments  to  Parti  1  to  3:  Transaction  Processing 
Security 

WDAMi  (SC21  N 
5232  to  ISO 
10026-12.3)  1991 

Informational 

(Draft) 

3.10.6.4.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.6.4.3  Standards  deficiencies.  There  are  no  mandated  standards  for  traffic  flow 
confidentiality. 

3.10.6.4.4  Portability  caveats.  Work  on  proposed  amendments  to  ISO  10026  has  ceased.  This 
is  a  high  portability  risk  area,  because  no  standards  exist 

3.10.6.4.5  Related  standards.  There  are  no  related  standards. 

3.10.6.4.6  Recommendations,  No  standards  are  recommended. 

SP3  is  the  basis  for  ISO  1 1577. 


I 
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3.10.7  Integrity.  Integrity  includes  systems  integrity,  data  integrity  techniques,  and  network 
integrity. 

3.10.7.1  Systems  integrity.  (This  BSA  appears  in  part  4  and  part  10.)  Systems  integrity 
objectives  ensure  the  integrity  of  information  and  resources  by  providing  a  level  of  protection  in 
response  to  the  threats  of  unauthorized  modification,  manipulation,  and  destruction  which  is 
commensurate  with  the  importance  and  priority  of  the  content  These  standards  provide  the  high- 
level  framework  with  which  to  view  the  security  service  of  integrity  in  open  systems. 

3.10.7.1.1  Standards.  Table  3.10-21  presents  standards  for  systems  integrity. 


TABLE  3.10-21  Systems  integrity  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

iH 

GPC 

DOD 

The  DOD  Trailed  Computer  System*  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trailed  Databaie  Management  Syrian  Interpretation  of  tbe 
Trailed  Computer  Syrian*  Evaluation  Criteria 

NCSC-Ta-021, 
Venion  1: 1991 

Mandated 

(Approved) 

IPC 

ISO 

ygggjggggggygi 

7498-2:1989 

Informational 

(Approved) 

[PC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1.0 

CC  Venion  1.0: 
1996 

Emerging 

(Draft) 

IPC 

ISO/IEC 

10i81-6 

Informational 

(Draft) 

IPC 

ITU-T 

X.815:  1993 

Informational 

(Drift) 

3.10.7.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.7.1  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.7.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.7.1.5  Related  standards.  The  following  NSA  documents  supplement  the  information  on 
integrity  found  in  the  TCSEC: 

a.  C  Technical  Report  79-91,  September  1991,  "Integrity  in  Automated  Information 
Systems: 

b.  C  Technical  Report  1 1 1-91,  October  1991,  "Integrity-Oriented  Control 
Objectives:  Proposed  Revisions  to  the  Trusted  Computer  System  Evaluation 
(TCSEC),  DOD  5200.28-STD." 

3.10.7.1.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.10.7.2  Data  integrity  techniques.  (This  BSA  appears  in  part  4  and  part  10.)  Data  integrity 
techniques  provide  services  that  allow  data  integrity  between  communicating  applications  to  be 
confirmed  by  means  of  a  cryptographic  check  function  using  a  block  cipher  algorithm,  by 
electronic  signature,  electronic  hashing,  and  encryption. 

3.10.7.2.1  Standards.  Table  3.10-22  presents  standards  for  data  integrity  techniques. 


TABLE  3.10-22  Data  integrity  techniques  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecvcle) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB  ISO- 
111995 

Mandated 

(Approved) 

GPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

IPC 

ISO 

Data  Cryptographic  Technique*  •  Data  Integrity 
Mechanim  Using  a  Cryptographic  Check  Function 
Employing  a  Block  Cipher  Algorithm 

9797:1989 

Informational 

(Approved) 

CPC 

IETF 

IP  Authentication  Header  (AH) 

RFC  1826:  1995 

Emerging 

(Draft) 

CPC 

IETF 

IP  Encapsulating  Security  Payload  (ESP) 

RFC  1827:  1995 

Emerging 

(Draft) 

CPC 

IETF 

Domain  Name  Syitem  (DNS)  Security  Extensions 

RFC  2065:1997 

Emerging 

(Draft) 

GPC 

NIST 

Secure  Hash  Standard  (SHS) 

FIPS  PUB 

180:1993 

Informational 

(Superseded) 

3.10.7.2.2  Alternative  specifications.  Alternative  de  facto  specifications  include  RSA  and  MD-5. 

3.10.7.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.10.7.2.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.10.7.2.5  Related  standards.  There  are  no  related  standards. 

3.10.7.2.6  Recommendations.  The  mandated  standards  re  recommended. 

FIPS  PUB  180-1,  which  supersedes  FIPS  PUB  180,  specifies  a  Secure  Hash  Algorithm  (SHA-1) 
which  can  be  used  to  generate  a  message  digest.  The  SHA-1  is  required  for  use  with  the  Digital 
Signature  Algorithm  (DSA)  as  specified  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  in 
federal  applications. 
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3.10.7.3  Network  integrity.  (This  BSA  appears  in  part  7  and  part  10.)  Network  integrity 
ensures  that  data  is  not  altered  or  destroyed  in  an  unauthorized  manner  when  transmitted  across  a 
network. 

3.10.7  J.1  Standards.  Table  3.10-23  presents  standards  for  network  integrity. 


TABLE  3.10-23  Network  integrity  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

Information  Tocfaolofy  •  Dafenaa  Standard  ixed  Profiled 
AMHXn(D)-  Meaaage  Handling  Syatema  •  Metaage 
Security  Protocol  (MSP)  Pam  1*5 

MIL-STD-2045- 

18500:  1993 

Mandated 

(Approved) 

ape 

NSA 

Secure  Data  Network  Syrtem  (SDNS)  Security  Protocol  3 
(SP3) 

SDN.301,  Re  virion 
1.5:  1989 

Mandated 

(ARjroved) 

NPC 

IEEE 

802.10b:  1992 

Le,.cy 

(Approved) 

IPC 

ISO 

Traruport  Layer  Security  Protocol  (TLSP)  (Indodei 
Amendment  1) 

10736:1994 

Informational 

(Approved) 

[PC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  I:  Overview, 
Modeii,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  4:  Protecting 
Traiufer  Syntax  Specification 

H58o-4:l994 

Informational 

(Approved) 

GPC 

NSA 

Secure  Data  Network  Syitem  (SDNS)  Security  Protocol  4 
(SP4) 

SDN.401,  Rev. 
1.3:1989 

Informational 

(Approved) 

ape 

Meriage  Security  Protocol  (MSP) 

SDN.701,  v.  4.0, 
Rev.  A:  1997 

Emerging 

(Approved) 

3.10.7 3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.7.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.10.7.3.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.10.7.3.5  Related  standards.  ITU-T  X.500  (1993)  (same  as  ISO  9594-1),  Information 
Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Overview  of  Concepts,  Models 
and  Services,  is  a  related  standard. 

3.10.7.3.6  Recommendations.  The  mandated  standards  are  recommended. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5,  1  August  1989.  MSP  is 
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under  revision  to  Version  4.0  to  accommodate,  in  part.  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

SP3  provides  connectionless  security  services  and  is  the  basis  for  ISO  11577.  SP3  is  designed  to 
be  used  at  the  top  of  layer  3. 

SP4  is  the  basis  for  ISO  10736. 

IEEE  802.10b  is  for  use  with  legacy  LANs  only. 
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3.10.8  Non-repudiation.  Non-repudiation  base  service  areas  include  systems  non-repudiation, 
electronic  signature,  and  electronic  hashing.  Non-repudiation  services  ensure  that  senders  and 
recipients  cannot  deny  the  origin  or  delivery  of  data.  Non-repudiation  mechanisms  can  be  used  to 
validate  the  source  of  software  packages  or  verifying  that  hardware  is  unchanged  from  its 
manufactured  state. 

3.10.8.1  Systems  non-repudiation.  (This  BSA  appears  in  part  5,  part  7,  part  10,  and  part  11.) 
These  standards  provide  the  security  services  for  non-repudiation  in  systems. 

3.10.8.1.1  Standards.  Table  3.10-24  presents  standards  for  systems  non-repudiation. 


TABLE  3.10-24  Systems  non-repudiation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

GPC 

DOD 

Information  Technology  -  Defense  Standardized  Profile* 
AMHXo(D)-  Message  Handling  Systems  •  Metuge 
Security  Protocol  (MSP)  Part*  1-5 

MIL-STD-2045- 

18500:  1993 

Mandated 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701,Rev.  3.0: 
1994 

(Approved) 

GPC 

NSA 

Message  Security  Protocol  (MSP) 

SDN.701,  v.  4.0. 
Rev.  A:  1997 

Emerging 

(Approved) 

IPC 

ISO 

Generic  Upper  Layer  Security  (GULS)  -  Part  1:  Overview, 
Models,  and  Notation 

11586-1:1994 

Informational 

(Approved) 

IPC 

ISO 

Generic  Upper  I>ayer  Security  (GULS)  -  Part  4:  Protecting 
Transfer  Syntax  Specification 

11586-4:1994 

Informational 

(Approved) 

IPC 

ISO 

7498-2:1989 

Information*! 
(Approved)  | 

CPC 

IETF 

IP  Authentication  Header  (AH) 

RFC  1826: 1995 

Emerging  | 

(Draft)  1 

CPC 

OMG 

Common  Object  Request  Broker  Architecture  (CORBA) 
Security 

OMG  95-12-1: 
1995 

Emerging  1 

(Draft)  | 

CPC 

IETF 

S/MIME  Message  Specification:  PKCS  Security  Seivice* 
for  MIME 

draft-dussc-  mime- 
msg-spec-OO.Ut, 
September  1996 

Informational  1 

(Draft)  [ 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Past  4:  Non- 
Repudiation  (same  as  ITU -TS  X.8I3) 

10181-4 

tnfonnalional 

(Draft) 

rpc 

ISO 

Non-Repudiation  Mechanisms  Part  1:  General  Model 

13888-1:1992 

(SC27  N868 
(Project 
1.27.06.01)) 

Informational 

(Draft) 

IPC 

ISO 

- 

Non-Repudiation  Medianimi  Part  2:  Using  Symmetric 
Encipherment  Algorithms 

13888-2:1994 

(SC27  N864 
(Project 
1.27.06.02)) 

Informational  jj 

(Draft)  [ 

IPC 

ISO 

Non-Repudiation  Mechanisms  Part  3:  Using  Asymmetric 
Techniques 

13888-3:1992 

(SC27  N869 
(Project 
1.27.06.03)) 

Informational  jj 
(Draft) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

WDAMa  (SC21  N 
5232  to  ISO 
10026-U.3)  1991 

Infotmabotul 

(D«ft) 

3.10.8.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.5.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.8.1.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.10.8.1.5  Related  standards.  FIPS  PUB  180- 1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.10.8.1.6  Recommendations.  The  mandated  standards  are  recommended  for  non-repudiation. 

MIL-STD-2045- 18500  describes  the  security  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5,  1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part.  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

MSP  provides  for  signed  receipts.  S/MIME,  an  Internet  Draft  specification,  does  not  provide  for 
signed  receipts. 
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3.10.8.2  Electronic  signature.  (This  BSA  appears  in  part  S,  part  7,  and  part  10.)  Electronic 
signature  is  the  process  that  operates  on  a  message  to  ensure  message  source  authenticity  and 
integrity,  and  source  non-repudiation.  Electronic  signatures  are  composed  so  that  the  identity  of  a 
signatory  and  integrity  of  the  data  can  be  verified. 

3.10.8.2.1  Standards.  Table  3.10-2S  presents  standards  for  electronic  signature. 


TABLE  3.10-25  Electronic  signature  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

Digital  Signature  Standard  (DSS) 

FIPS  PUB 
186:1994 

Mandated 

(Approved) 

IPC 

ISO 

Digital  Signature  Scheme  Giving  Message  Recovery 

9796:1991 

Informational 

(Approved) 

CPC 

IE  tV 

Privacy  Enhance™  ?nt  for  Internet  Electronic  Mail 

RFC  1421- 
1424:1993 

Informational 

(Draft) 

IPC 

ISO 

Digital  Signature  with  Appendix  -  Part  1:  General 

SC27/WG2  N294 

(Pn.  :ect 

1.27.U.01) 

Informational 

(Formative) 

[PC 

ISO 

Digital  Signature  with  Appendix  •  Part  2:  Identity- Baied 
Mechaniaou 

SC27/WG2  N295 

(Project 

1.27.08,02) 

Informational 

(Formative) 

IPC 

ISO 

Digital  Signature  with  Appendix  -  Part  3:  Certificate-Bared 
Mechanism* 

SC27/WG2  N296 

(Project 

1.27.08.03) 

Informational 

(Foimalive) 

3.10.8.2.2  Alternative  specifications.  Rivest-Shamir-Adelman  (RSA)  Public  Key  Algorithm  RC- 
5  was  developed  and  published  in  1994.  It  is  proprietary,  but  RSA  Data  Security  is  working  to 
have  it  included  in  numerous  Internet  standards.  At  present,  RC-5  is  not  recommended  for  DOD 
use  because  it  is  proprietary. 

3.10.8.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.8.2.4  Portability  caveats.  DSS  applications  are  not  interoperable  with  non-DSS  systems. 

3.10.8.2.5  Related  standards.  FIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.10.8.2.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  186  is 
implemented  in  the  FORTEZZA  n-yptographic  card,  a  PC  card  (formerly  called  a  Personal 
Computer  Memory  Card  International  Association  (PCMCIA)  standard  card)  that  can  be 
integrated  into  personal  computers  and  workstations  to  provide  security  in  commercial 
applications.  FORTEZZA  is  being  used  in  the  Defense  Message  System.  FIPS  PUB  186  is  the 
government-wide  key  cryptographic  signature  system. 
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3.10.8.3  Electronic  hashing.  (This  BSA  appears  in  part  5,  part  7,  part  8,  and  part  10.) 
Electronic  hashing  services  compute  a  condensed  representation  of  a  '"-ssage  or  a  data  file,  often 
used  as  a  measure  of  data  integrity  checking. 

3.10.8.3.1  Standards.  Table  3.10-26  presents  standards  for  electronic  hashing. 


TABLE  3.10-26  Electronic  hashing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Secure  Huh  Standard  (SHS) 

FIPS  PUB  180- 
1:1995 

Mandated 

(Approved) 

IPC 

ISO 

Hash  Fuoctioru,  Pan  1 :  General  Model 

10118-1:1994 

Informational 

(Approved) 

IPC 

ISO 

10118-2:1994 

Informational 

(Approved) 

GPC 

NIST 

Secure  Hath  Standard  (SHS) 

FIPS  PUB 
180:1993 

Informational 

(Superseded) 

IPC 

ISO 

Hath  Function*,  Part  3:  Dedicated  Hath  Function! 

WD  10118-3, 
JTC1/SC27  N883 
(Project 
t. 27.09.03) 

Informational 

(Draft) 

IPC 

ISO 

Hath  Fwctioru,  Part  4:  Hath  Function*  Using  Modular 
Arithmetic 

WD  10118-4, 
JTC1/SC27  N884 
(Project 
1.27.09.04) 

Informational 

(Draft) 

3.10.8.3.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3. 10.8.3  .3  Standards  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.10.8.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.8.3.5  Related  standards.  FIPS  PUB  180-1  supersedes  FIPS  PUB  180  and  is  required  for 
use  with  FIPS  PUB  186,  Digital  Signature  Standard. 

3.10.8.3.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  180-1 
specifies  SHA,  which  can  l  tsed  to  generate  a  message  digest.  SHA  is  required  for  use  with  the 
DSA  as  specified  in  FIPS  PUB  186  and  whenever  an  SHA  is  required  for  federal  applications. 
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3.10.9  Systems  availability.  System  availability  objectives  ensure  service  availability  consistent 
with  the  operational  importance  of  the  information  or  valued  assets. 

3.10.9.1  Detection  and  notification.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.) 
Detection  and  notification  objectives  ensure  that  a  secure  system  has  the  capability  to  recognize 
that  it  is:  under  attack;  may  potentially  enter  a  non-available  state;  has  been  compromised;  or  has 
failed  in  a  potentially  compromising  manner.  Guidance  in  this  area  focuses  on  reporting  detected 
security  critical  conditions  to  proper  authorities,  and  implementing  predetermined  corrective 
actions. 

3.10.9.1.1  Standards.  Table  3.10-27  presents  standards  for  detection  and  notification. 


TABLE  3.10-27  Detection  and  notification  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trotted  Computer  Sy item*  Evaluation  Criteria 

DOD  5200.28* 

STD:  1985 

Mandated 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1.0 

CC  Venion  1.0: 
1996 

Emerging 

(Draft) 

3.10.9.1 .2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.9.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.9.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.19.9.1.5  Related  standards.  NSA's  C-Technical  Report-001,  Computer  Viruses:  Prevention, 
Detection,  and  Treatment,  and  NIST  SP  800-5,  A  Guide  to  the  Selection  of  Anti-Virus  Tools  and 
Techniques,  provide  guidance  on  computer  viruses.  The  following  specifications  support  the 
TCSEC  stand.".; . 


a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-015,  Version  1,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

c.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.10.9.1.6  Recommendations.  Tb'  mandated  standard  is  recommended. 
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3.10.9.2  Security  recovery.  (This  BSA  appears  in  part  2,  part  9,  and  part  10.)  Recovery 
guidance  defines  provisions  to  allow  system  personnel  or  processes  with  the  proper  authorizations 
to  repair  or  eliminate  the  cause  of  security  relevar  t  failures,  isolate  compromised  potions  of  the 
system,  and  revalidate  proper  operations  prior  to  returning  the  system  to  a  fully  operational  secure 
state. 

3.10.9 .2.1  Standards.  Table  3.10-28  presents  standards  for  security  recovery. 


TABLE  3.10-28  Security  recovery  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mi 

GPC 

DOD 

The  DOD  Trailed  Computer  Syitemi  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Venion  1,0 

CC  Venion  1.0: 
1996 

Emerging 

(Draft) 

3.10.9.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.9.2  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.9.2.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.10.9.2.5  Related  standards.  The  following  specifications  are  related  to  the  TCSEC  standard: 

a.  NCSC-TG-005,  Version  1,  July  1987,  Trusted  Network  Interpretation 

b.  NCSC-TG-022,  Version  1,  December  1991,  A  Guide  to  Understanding  Trusted 
Recovery  in  Trusted  Systems 

c.  NCSC-TG-015,  Version  1,  October  1989,  A  Guide  to  Understanding  Trusted 
Facility  Management 

d.  NCSC-TG-016,  Version  1,  October  1992,  Guidelines  for  Writing  Trusted  Facility 
Manuals 

3.10.9.2.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.10.10  Security  labeling.  Security  labeling  is  the  data  bound  to  a  resource  (which  may  be  a  data 
unit)  that  names  or  designates  the  security  attributes  of  that  resource.  Security  labeling  includes 
security  labeling  for  the  following  major  service  areas:  user  interface,  data  manaement,  data 
interchange,  graphics,  network  (data  communications),  system,  and  distributed  computing. 

3.10.10.1  User  interface  security  labeling.  (This  BSA  appears  in  part  3  and  part  10.)  User 
interface  security  labeling  provides  a  human  readable  representation  of  the  internal  security  labels 
associated  with  data  management,  data  interchange,  graphics,  data  communications,  system,  and 
distributed  computing  services. 

3.10.10.1.1  Standards.  Table  3.10-29  presents  standards  for  user  interface  security  labeling. 


TABLE  3.10-29  User  interface  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

iil 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

GPC 

DOD 

Compartmented  Mode  WorktUrion  (CMW)  Evaluation 
Criteria 

Adopted 

(Approved) 

GfC 

DOD 

CMW  Labeling:  Encoding  Format 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  Uaer  Interface 
Guideline*,  Revirion  1 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Defeme  Intelligence  Agency  Standard  U*er  Interface  Style 
Guide  for  Compartmented  Mode  Work*  tab  on* 

DIA  Style  Guide: 
1983 

Informational 

(Approved) 

3.10.10.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.10.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

,3.10.10.1.5  Related  standards.  DOD  5200.28-STD  is  a  related  standard.  DOD  5200. 1-R, 
"Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy  for  security 
classification,  declassification,  and  marking  of  DOD  information.  It  also  contains  DOD  policy  for 
safeguarding  of  classified  information,  including  accountability,  storage,  transmission,  and 
destruction  of  the  information. 

Security-related  interface  requirements  for  workstations  operating  in  System  High  or 
Compartmented  Mode  are  discussed  in  DDS-2600-6243-91  and  the  DLA  Style  Guide,  which 
provide  the  basis  for  the  security  portion  of  the  HCi  Style  Guide  (TAFIM  Volume  8). 

3.10.10.1.6  Recommendations.  Appendix  A  of  the  TAFIM.  Volume  8,  DOD  HCI  Style  Guide, 
outlines  security:  presentation  guidelines  for  workstations  and  is  recommended. 
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3.10.10.2  Data  management  security  labeling.  (This  BSA  appears  in  part  4  and  part  10.)  Data 
management  security  labeling  provides  a  security  service  for  ensuring  that  data  includes  labeling 
information  in  support  of  mandatory  access  control  security  services,  marlring  security  services, 
handling  security  services,  aggregation  security  services,  sanitization  security  services,  and  release 
security  services.  Security  labeling  services  produce  and  maintain  the  integrity  of  the  security  label 
and  its  binding  to  the  data  with  which  it  is  associated. 

3.10.10.2.1  Standards,  Table  3.10-30  presents  standards  for  data  management  security  labeling. 


TABLE  3.10-30  Data  management  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  19811 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS -2600-62 16- 

91 

Informational 

(Approved) 

GPC 

DOD 

Informational 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

3.10.10.2.2  Alternative  specifications.  There  are  no  alternative  standards. 

3.10.10.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.2.4  Portability  caveats.  Portability  problems  with  the  existing  standards  arc  unknown. 

3.10.10.2.5  Related  standards.  Data  management  security  labeling  should  be  compatible  with 
MIL-STD-2045-48501,  Common  Security  Label,  for  any  system  with  a  communications 
interface. 

DOD  5200.1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information, 

3.10.10.2.6  Recommendations.  The  mandated  standard  is  recommended.  Data  management 
security  labeling  should  be  based  of  the  operating  system  security  label  standards.  Data 
management  security  labeling  should  employ  binding  of  strength  equal  to  or  greater  than  that  of 
the  operating  system.  Compatible  security  labeling  standards  include  the  ability  to  perform  a  one- 
for-one  mapping  or  translation  between  security  labeling  standards. 
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3.10.10.3  Data  interchange  security  labeling.  (This  BSA  appears  in  part  S  and  part  10.)  Data 
interchange  security  labeling  provides  a  security  service  to  define  the  format  and  correctly  parse  a 
security  label  into  the  security  attributes  used  by  other  security  services. 

3.10.103.1  Standards.  Table  3.10-31  presents  standards  for  data  interchange  security  labeling. 


TABLE  3.10-31  Data  interchange  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Common  Security  Label  (CSL) 

MIL-STD-2045- 
48501:  1995 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  and  User  Interface 
Guidelines,  Revision  1 

Informational 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

Informational 

(Approved) 

GPC 

NIST 

Standard  Security  Label  (SSL)  for  Information  Transfer 

FIPS  PUB 
188:1994 

Informational 

(Approved) 

IPC 

ITU-T 

Message  Handling  Systems:  Message  Transfer  System: 
Abstract  Service  Definition  and  Procedures 

X.411: 1992 

Informational 

(Approved) 

CPC 

TSIG 

Trusted  Security  Information  Exchange  for  Restricted 
Environments 

TSIX  (RE)  1.1 

Emerging 

(Draft) 

3.10. 10.33  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.10.33  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.3.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.10.33  Related  standards.  DOD  5200.28-STD  is  a  related  standard. 

DOD  5200.1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information. 

3.10.10.3.6  Recommendations.  The  mandated  standard  is  recommended.  TS1G  TSIX(RE)  1 . 1 
includes  options  compatible  with  MIL-STD-2045 -48501. 
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3.10.10.4  Graphics  security  labeling.  (This  BSA  appears  in  part  6  and  part  10.)  Graphics 
security  labeling  provides  a  security  service  for  ensuring  that  graphical  data  includes  labeling 
information  in  support  of  mandatory  access  control  security  services,  marking  security  services, 
handling  security  services,  aggregation  security  services,  .sanitization  security  services,  and  release 
security  services.  Security  labeling  services  produce  and  maintain  the  integrity  of  the  security  label 
and  its  binding  to  the  data  with  which  it  is  associated. 

3.10.10.4.1  Standards.  Table  3.10-32  presents  standards  for  graphics  security  labeling. 


TABLE  3.10-32  Graphics  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ill 

GPC 

DOD 

The  DOD  Trutfed  Computer  Sy items  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-6216- 

91 

Informational 

(Approved) 

GPC 

DOD 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Compartmoited  Mode  Workstation  (CMW)  Evaluation 
Criteria 

■mu 

Informational 

(Approved) 

3.10.10.4.2  Alternative  specifications.  There  are  no  other  specifications. 

3.10.10.4.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.4.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.10.4.5  Related  standards.  Graphics  security  labeling  should  be  compatible  with  MIL-STD- 
2045-48501,  Common  Security  Label,  for  any  system  with  a  communications  interface. 

DOD  5200.1-R,  "Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy 
for  security  classification,  declassification,  and  marking  of  DOD  information.  It  also  contains 
DOD  policy  for  safeguarding  of  classified  information,  including  accountability,  storage, 
transmission,  and  destruction  of  the  information. 

3.10.10.4.6  Recommendations.  The  mandated  standard  is  recommended.  Graphics  security 
labeling  should  be  based  on  the  operating  system  security  label  standards.  Graphics  security 
labeling  should  employ  binding  of  strength  equal  to  or  greater  than  that  of  the  operating  system. 
Compatible  security  labeling  standards  include  the  ability  to  perform  a  one-for-one  mapping  or 
translation  between  security  labeling  standards. 
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3.10.10.5  Data  communications  security  labeling.  (This  BSA  appears  in  part  7  and  part  10.) 
Data  communications  security  labeling  encompasses  the  application  of  security  labeling,  which  is 
used  as  the  basis  for  mandatory  access  control  security  services  and  release  security  services. 

3.10.10.5.1  Standards.  Table  3.10-33  presents  standards  for  data  communications  security 
labeling. 


TABLE  3.10-33  Data  communications  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Common  Security  Label  (CSL) 

MIL-STD-2045- 
48501:  1995 

Mandated 

(Approved) 

IPC 

ISO 

Transport  Layer  Security  Protocol  (TLSP)  (Includes 
Ameotfcnent  1) 

10736:1994 

Informational 

(Approved) 

IPC 

ISO 

Network  Layer  Security  Protocol  (NLSP) 

11577:1994 

Informational 

(Approved) 

IPC 

ISO 

7498-2:1989 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

innii 

Informational 

(Approved) 

GPC 

DOD 

Informational 

(Approved) 

GPC 

DOD 

Compartmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

GPC 

NIST 

Standard  Security  Label  (SSL)  for  Information  Transfer 

FIPS  PUB 
188:1994 

Informational 

(Approved) 

CPC 

IETF 

DoD  Security  Options  for  the  Internet  Protocol 

RFC  1108:1991 

Lcgtcy 

(Draft) 

CPC 

IETF 

Revised  Internet  Protocol  Security  Options  (RIPSO) 

RFC  1038:1988 

Informational 

(Draft) 

CPC 

TSIG 

Touted  Security  Information  Exdtange  for  Restricted 
Environments 

TS1X(RE)  1.1 

Emerging 

(Draft) 

NPC 

IEEE 

Standard  for  Interoperable  LAN  Security-Part  G:  Standard 
for  Security  Labeling  within  Secure  Data  Exchange 

802.l0g/D7 

Emerging 

(Draft) 

3.10.10.5.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.10.5.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.5.4  Portability  caveats.  Portability  problems  related  to  the  existing  standards  are 
unknown. 

3.10.10.5.5  Related  standards.  DOD  5200.28-STD  is  a  related  standard.  DOD  5200.1-R, 
"Information  Security  Program  Regulation,"  June  1986,  establishes  DOD  policy  for  security 
classification,  declassification,  and  marking  of  DOD  information.  It  also  contains  DOD  policy  for 
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safeguarding  of  classified  information,  including  accountability,  storage,  transmission,  and 
destruction  of  the  information. 

3.10.10.5.6  Recommendations.  The  mandated  standard  is  recommended  and  should  be  used  for 
new  acquisitions.  MIL- STD-2045-48 50!  supports  the  exchange  of  security  attributes,  for 
example,  sensitivity  labels.  It  provides  a  means  to  label  and  protect  data  as  it  passes  through 
communications  systems  and  implements  FIPS  PUB  188  for  the  DOD  environment  MIL-STD- 
2045-48501  and  FIPS  PUB  188  apply  only  to  layers  3  and  4.  TSIG  TSDC(RE)  1.1,  "Trusted 
Systems  Interoperability  Group,  Trusted  Security  Information  Exchange  for  Restricted 
Environments,"  includes  options  compatible  with  MIL-STD- 2045-4850'. 

IEEE  802.  lOg  is  consistent  with  the  SSL  and  the  CSL. 

RFC  1 108  makes  RFC  1038  obsolete.  RFC  1 108  should  be  used  for  legacy  systems  only.  RFC 
1038  is  not  recommended. 
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3.10.10.ti  Operating  system  security  labeling.  (The  BSA  appears  in  part  8  and  part  10.) 
Operating  system  security  labeling  provides  a  security  labeling  service  in  support  of  end  system 
processing.  This  service  is  required  to  support  similar  or  shared  service  for  all  other  MSAs 
having  security  labels.  This  service  includes  any  translation  services  to  support  other  MSAs, 
achieve  host  system  independence,  or  protect  host  identity. 

3.10.10.6.1  Standards.  Table  3.10-34  presents  standards  for  operating  system  security  labeling. 


TABLE  3.10-34  Operating  system  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trailed  Computer  Syitemi  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-6216- 

91 

Informational 

(Approved) 

GPC 

DOD 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

Corupartmcnted  Mode  Woriuurion  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

NPC 

fPPP. 

Standard  for  Interoperable  LAN  Security -Part  G:  Standard 
for  Security  Labeling  within  Secure  Data  Exchange 

802.10g/D7 

Emerging 

(Draft) 

3.10.10.6.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.10.6 3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.10.10.6.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.10.6.5  Related  standards.  DOD  5200. 1-R,  "Information  Security  Program  Regulation," 
June  1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of 
DOD  information.  It  also  contains  DOD  policy  for  safeguarding  of  classified  information, 
including  accountability,  storage,  transmission,  and  destruction  of  the  information. 

3.10.10.6.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.10.10.7  Distributed  computing  security  labeling.  (This  BSA  appears  both  in  part  10  and  part 
11.)  Distributed  computing  security  labeling  provides  a  security  labeling  service  to  support 
mandatory  access  controls  within  a  distributed  environment 

3.10.10.7.1  Standards.  Table  3.10-35  presents  standards  for  distributed  computing  security 
labeling. 


TABLE  3.10-35  Distributed  computing  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trailed  Computer  System*  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Trusted  Database  Management  System  Interpretation  of  the 
Trusted  Computer  System*  Evaluation  Criteria 

NCSC-TG-Q21, 
Version  1: 1991 

Mandated 

(Approved) 

DOD 

Compaitmented  Mode  Workstation  (CMW)  Evaluation 
Criteria 

DDS-2600-6243- 

92 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Source  Code  utd  liter  Interface 
Guideline!.  Re  virion  1 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

DDS-2600-6216- 

91 

Informational 

(Approved) 

[pc 

ISO 

OSI  Brute  Reference  Model,  Put  2:  Security  Architecture 
(»«ne  at  CCITT  X.800. 1 99! ) 

7498-2:1989 

Informational 

(Approved) 

3.13.10.7.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.10.10.7.3  Standards  deficiencies.  The  subjects  and  objects  requiring  security  labeling  in  a 
distributed  computing  environment  have  not  been  standardized  or  identified  in  any  standardized 
framework. 

3.10.10.7.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.10.10.7.5  Related  standards.  DOD  5200. 1-R,  "Information  Security  Program  Regulation," 
June  1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of 
DOD  information.  It  also  contains  DOD  policy  for  safeguarding  of  classified  information, 
including  accountability,  storage,  transmission,  and  destruction  of  the  information. 

3.10.10.7.6  Recommendations.  The  mandated  standards  are  recommended. 

The  DGSA  (TAFIM  Volume  6)  provides  general  architectural  guidance  for  information  domains 
which  can  exist  in  a  distributed  environment.  The  properties  of  information  domains  share  some 
similarities  with  security  labels  in  a  distributed  environment. 
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3.11  Distributed  computing.  Distributed  computing  provides  services  and  tools  that  support  the 
creation,  use,  and  maintenance  of  distributed  applications  in  a  heterogeneous  computing 
environment  This  includes  specialized  support  for  applications  that  may  be  physically  or  logically 
dispersed  among  computer  systems  in  a  heterogeneous  network,  but  yet  wish  to  maintain  a 
cooperative  processing  environment  The  classical  definition  of  a  computer  becomes  blurred  as 
the  processes  that  contribute  to  information  processing  become  distributed  across  a  facility  or  a 
network.  As  with  other  cross-cutting  services  the  requisite  components  of  distributed  computing 
services  typically  exist  within  particular  service  areas.  They  are  described  in  subsequent 
paragraphs  but  include  global  time,  data,  file,  name,  remote  procedure  call,  security  and  threads. 
NOTE:  throughout  Part  1 1,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus=NPC 

b.  International  Public  Consensus=IPC 

c.  Government  Public  Consensus=GPC 

d.  Consortia  Public  Consensus=CPC 

e.  Consortia  Private  Non-Concensus=CPN-C 

f.  National  Public  Non-Consensus=NPN-C 

3.11.1  Introduction  and  overview  of  distributed  computing  (general  discussion).  Distributed 
computing  services  allow  users  and  application  developers  to  maximize  the  computing  power 
found  in  today's  networks  by  transparently  assigning  tasks  to  the  most  appropriate  processors. 

The  software  in  distributed  computing  systems  will  mask  the  specific  data  formats  of  each 
machine  and  allow  access  to  all  applications  from  any  platform  on  the  network.  (Air  Force 
Technical  Reference  Code) 

3.11.2  Client/Server.  Architecture  in  which  the  client  (personal  computer  or  workstation)  is  the 
requesting  machine  and  the  server  is  the  supplying  machine  (LAN  file  server,  mini,  or  mainframe). 
The  client  provides  the  user  interface  and  performs  some  or  all  of  the  application  processing.  The 
server  maintains  the  database  and  processes  requests  from  the  client  to  extract  data  from  or 
update  the  database.  The  server  also  controls  the  application's  integrity  and  security. 

Distributed  client/server  systems  allow  applications  to  interoperate  on  a  variety  of  platforms 
regardless  of  the  manufacturer  of  the  underlying  hardware,  operating  system,  or  networking 
software.  They  include  such  services  as:  remote  procedure  call  which  lets  applications,  or 
portions  of  applications,  call  for  a  procedure  from  a  remote  system;  naming  services  which  let 
users  access  network  services  by  name  without  the  necessity  of  knowing  where  the  resource  is 
located;  and  timing  services  which  regulate  system  clocks  on  each  network  computer  so  that  they 
match  each  other. 

3.11.2.1  Threads.  (This  BSA  appears  in  both  part  8  and  part  1 1.)  A  traditional  UNIX  process 
has  a  single  thread  of  control.  A  thread  of  control,  or  more  simply  a  thread,  is  a  sequence  of 
instructions  executed  in  a  program  A  thread  has  a  program  counter  (PC)  and  a  stack  io  keep 
track  of  local  variables  and  return  addresses.  A  thread  is  one  transaction  or  message  in  a 
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multithreaded  system  or  an  individua’  irocess  within  a  single  application.  Thread  interfaces  are 
specifications  for  interfacing  with  these  processes. 

Thread  services  provide  an  underlying  service  for  multiple  concurrent  executions  within  a  single 
computer  process.  They  are  designed  to  allow  independent  operation  and  are  essential  for 
functions  such  as  multiple  process  communications  in  a  distributed  computing  environment 
Threads  provide  improved  software  responsiveness  through  increased  use  of  the  inherent 
synchronous  execution  (i.e.,  parallels  r)  of  programs.  The  threads  service  in  DCE  allows  all 
DCE-enabled  applications  to  execute  multiple  actions  simultaneously.  Applications  can  accept 
information  from  users,  execute  RPCs,  and  access  databases  at  the  same  time.  The  threads 
service  is  used  by  several  DCE  services,  including  the  RPC,  Security,  Directory,  and  Time 
Services.  The  OSF  has  designed  the  threads  service  to  be  easily  accessible  by  programmers 
wishing  to  use  it  in  applications.  Services  can  be  accessed  through  the  C  programming  language, 
and  through  other  high-level  programming  languages. 

3.11.2.1.1  Standards.  Table  3.1 1-1  presents  standards  for  threads. 


TABLP  3.11-1  Threads  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/EC 

Portable  Operating  Syrtem  Interface  (POSDf)  Part  1: 
System  API  (Replace!  ISO  9945-1:1990  and  incorporate* 
EEE  1003.1b,  1003.1c,  and  1003.  li) 

9945-1:1996 

Mandated 

(Approved) 

CPN-C 

Microsoft 

Window  Management  and  Graphic!  Device  Interface, 
Volume  1  Icrosoft  Win32  Programmer*'  Reference 
Manual.  1993.  Microsoft  Press 

Win32  APIs 

Mandated 

(Approved) 

NPC 

EE7. 

PGSIX  Part  1 :  Syrtem  Application  Program  Interface 
(API)  Amendment  2:  Thread!  Extension  [C  Language) 

1003.1c:1995 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Thread! 
(baied  on  the  draft  4  version  of  EEE  1003.1c.) 

DCE  1.1 
Threads:  1994 

Informational 

(Approved) 

NPC 

IEFJ 

POSDC-Pait  1:  Syrtem  API  -  Amend,  n:  Technical 
Corrigenda  to  Threads  API  Extensions  (C  Language) 

PI003.li! 

Emerging 

(Formative) 

CPC 

X,Open 

npen  Threads  Extension 

Aspen  Threads 

Informational 

(Formative) 

3.11.2.1.2  Aiternative  specification,  ,n;  OSF/1  Operating  System's  Mach-Based  Multithreaded 
Kernel  is  also  available. 

3.1 1.2. 1 J  Standard  deficiencies.  Because  the  Pthreads  interface  is  not  designed  specifically  for 
Ada,  it  can  impose  s  great  overhead  Darden  on  an  Ada  run-time  system.  The  Ada  rendezvous 
feature  is  not  supported  by  Pthreads,  which  is  a  major  problem  for  real  time  applications. 

OSF  DCE  Threads  are  incompatible  with  Ada  Tasking.  Programmers  can  use  one  or  the  other, 
but  not  both.  Since  DCE  Threads  underlie  OSF  RPC,  Ada  programmers  should  be  cautious  in  the 
■se  of  tasking.  (Reference:  Understanding  DCE  by  Rosenberry,  Kenney,  and  Fisher) 
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3.11.2.1.4  Portability  caveats.  Ada83  and,  to  an  even  greater  extent,  Ada9x  already  contain 
many  of  the  capabilities  defined  in  the  1003.  lc  standard.  This  can  cause  many  conflicts  with  Ada. 
Vendors  may  implement  Ada  tasks  in  a  way  that  interferes  with  the  implementation  of  Pthreads. 
Also,  if  the  Ada  vendor  does  not  implement  tasks  as  Pthreads,  conflicts  may  arise  between  what 
Ada  can  and  cannot  do  and  what  Pthreads  can  do.  For  example,  die  Ada  rendezvous  feature  is 
not  supported  by  Pthreads.  On  the  other  hand,  Pthreads  provides  some  extended  features,  such  as 
dynamic  priorities,  that  have  not  been  standardized  by  the  Ada  language,  but  that  are  in  demand, 
especially  by  real  time  users. 

3.11 .2.1.5  Related  standards.  The  following  standards  are  related  to  threads  services: 

a.  IEEE  P1003.1e:  Security  Interface  Standards  for  POSIX. 

b.  IEEE  P1003.21:  POSIX  -  Real  Time  Distributed  Systems  Communication. 

c.  NIST  FIPS  151-2:1993,  Portable  Operating  System  Interface  (POSIX)-System 
Application  Program  Interface  [C  Language]  (ISO/IEC  9945-1:1990)  1993. 

3.11.2.1.6  Recommendations.  The  mandated  standards  are  recommended.  The  operating  system 
standards  mandated  by  the  JTA  Version  1.0:1996  (ISO/IEC  9945-1:1990,  IEEE  1003.1b:1993, 
IEEE  1003.1c:1995,  and  IEEE  1003.  li:  1995)  are  all  incorporated  in  the  new  ISO/IEC  9945- 
1:1996.  TheOSFDCEthreadsisbasedonadraftversionoflEEEP1003.1c Pthreads.  OSF 
intends  to  move  to  the  new  IEEE  1003.  lc  standard  in  a  future  version  of  DCE.  In  the  meantime, 
DCE  users  should  specify  DCE  threads  to  ensure  compatibility  with  currently  available  DCE 
products.  However,  they  should  also  specify  that  these  products  will  be  able  to  migrate  to  the 
new  version  of  DCE  when  OSF  adopts  the  approved  1003.1c  standard. 

To  the  extent  an  Ada  runtime  system  uses  standard  POSIX  interfaces,  it  will  be  portable  across 
operating  systems  compliant  with  POSIX.  Some  of  the  problems  caused  by  Ada  operations  not 
currently  mapped  to  Pthreads  will  be  resolved  by  the  Ada  binding  to  the  1003.  lc  Pthreads 
standard. 
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3.11.2.2  Remote  procedure  call.  (This  BSA  appears  in  part  8  and  part  11.)  Remote  procedure 
call  (RPC)  is  a  communication  service  to  transfer  procedure  calls  to  a  remote  server  and  return 
results,  errors,  or  associated  call  backs  (ECMA  127).  The  RPC  extends  the  local  procedure  call 
to  a  distributed  environment  In  a  RPC,  a  process  can  invoke  a  remote  procedure  as  if  it  were 
invoking  a  local  procedure.  SC2 1/WG6  proposes  to  address  RPC  using  Interface  Definition 
Notation  (IDN)  that  is  based  on  abstract  data  types  rather  than  on  a  union  of  programming 
language-specific  data  types. 

3,11.2.2.1  Standards.  Table  3.1 1-2  presents  standards  for  remote  procedure  call. 


TABLE  3.11-2  Remote  procedure  call  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSP 

DCE  1.1  RPC:  1994 

Mandated 

(Approved) 

CPC 

XJOptxi 

X/Open  DCE:  Remote  Procedure  Cell 

C309  (8/M) 

Informational 

(Approved) 

CPC 

IETF 

Open  Netwodt  Computing  (SUN  ONC)  Remote  Procedure 
Call  (RPC) 

RFC  1057:1988 

Informational 

(Approved) 

IPC 

ISO 

OSI  Remote  Procedure  Call  (RPC)  (Replaced  DIS  11578 
PT  1  Thru  PT  4) 

11578.2 

Informational 

(Draft) 

NPC 

IEEE 

PQSK  -  Part  1:  Protocol  Independent  interface* 

P1003.1g 

Emerging 

(Draft) 

NPC 

IEEE 

POSIX  -  Part  1:  System  API  Amendment:  Real-Tune 
Diatributed  System*  Communication* 

P1003.21 

Emerging 

(Draft) 

3.11.2.2.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.11.2.2 3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.11.2.2.4  Portability  caveats.  All  the  indicated  RPCs  are  unique.  They  do  not  interoperate. 
Systems  using  different  RPCs  are  not  interoperable,  nor  are  their  applicatio1  s  portable  across 
different  RPCs.  No  RPC  conformance  tests  are  available. 

3.11.2.2.5  Related  standards.  The  following  standards  are  related  to  RPC: 

a.  Common  Language  Independent  Data  Types  (CLID)  (ISO  1 1404). 

b.  Common  Language  Independent  Procedure  Call  Mechanism  (CLIP  or  CLIPCM). 
SC22/WG1 1  has  recommended  that  there  should  be  a  cross  reference  between  the 
standards. 

c.  NIST  FIPS  146-1:1991:  Government  Open  Systems  Interconnection  Profile 
(GOSIP),  ISO  8822,  ISO  8823  (SIA-5.8)  Presentation  (Layer  6),  Session  (Layer 
5)  ISO  8327  (S1A-5.9). 
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d.  NIST  FIPS  146-2  POSIT:  May  1995. 

3.11.2.2.6  Recommendations.  The  Open  Software  Foundation  (OSF)  Distributed  Computing 
Environment  (DCE)  is  recommended.  A  migration  path  to  the  ISO  RPC  also  should  be  required 
as  soon  as  that  standard  is  in  final  form. 

The  IEEE  P1003.21  draft  standard  includes  interfaces  for  the  support  of  request/response 
services. 
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3.11.2.3  Distributed  timing  service.  (This  BSA  appears  in  part  8  and  part  11.)  Distributed 
timing  service  (DTS)  guarantees  synchronization  among  all  system  clocks  in  a  distributed 
network.  Synchronized  timing  is  necessary  to  maintain  scheduling  of  activities  and  sequencing  of 
events.  DTS  uses  RPC  in  the  communications  between  DTS  clients  and  DTS  servers.  It  also 
uses  RPC  in  the  protocol  between  a  Time  Server  and  a  Time  Provider.  Since  DTS  is  based  on 
DCE  RPC,  which  uses  DCE  Threads,  DTS  also  uses  Threads.  DTS  depends  on  CDS  to  find 
Time  Servers  and  their  locations.  GDS  may  be  used  indirectly  if  a  Global  Time  Server  is 
registered  in  a  foreign  cell  registered  in  the  X.500  namespace.  DTS  uses  the  DCE  Security 
Service  to  authenticate  its  interactions. 

3.11.2.3.1  Standards.  Table  3.1 1-3  presents  standards  for  distributed  timing  service. 


TABLE  3.11-3  Distributed  timing  service  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Time  Service  (DTS) 

DCB1.I 

DTS:  1994 

Mandated 

(Approved) 

CPC 

IETF 

Netwoik  Time  Protocol  (V3) 

RFC  1305:1992 

Mandated 

(Approved) 

CPC 

X/Op<fi 

X/Open  DCE;  Time  Serviced 

C3 10  (11/54) 

Informational 

(Approved) 

NPC 

IEEE 

POSIX  -  Pert  1 :  Advanced  Realtime  System  API  Extension 
(C  Language  Binding) 

P1003.  lj 

Emerging 

(Draft) 

NPC 

IEEE 

POSIX  -  Part  1 :  System  API  Amendment:  Real-Time 
Distributed  Systems  Commumcatioru 

P1003.21 

Emerging 

(Draft) 

3.11.2.3.2  Alternative  specifications.  The  following  specification  is  available: 

a.  SAE  ARD  50067  Draft:  Avionics  Operating  System  API  Requirements. 

3. 1 1.2.33  Standards  deficiencies.  ISO/IEC  9945-1:1996  which  incorporates  IEEE  1003.1b 
contains  time  services  related  to  high  resolution  real  time  timers,  but  internationalization  and 
highly  functional,  system-wide  clocks  are  beyond  its  scope.  The  IEEE  P1003.1j  draft  standard 
extends  the  model  of  1003.1b  Clocks  and  Timers  to  include  access  to  a  monotonic  clock  and  a 
synchronized  clock;  however,  like  1003.  lb,  the  actual  implementation  of  these  clocks  is  beyond 
the  scope  of  the  standard. 

To  date,  there  is  no  standardized  API  for  the  management  of  distributed  time  services.  However, 
the  IEEE  PI 003.21  working  group  intends  to  develop  an  API  for  time  management  services, 
which  would  include  such  time  management  protocols  as  NTP  and  DTS. 

3.11.2.3.4  Portability  caveats.  If  the  time  services  are  to  be  used  in  building  internationalized 
programs,  portability  is  unlikely.  Behavior  is  not  portable  across  systems  in  whicn  one  supports 
the  nanosecond-resolution  timers  specified  by  the  S'VID  and  Berkeley  Unix.  However,  the  IEEE 
P1003.  lj  draft  standard  provides  applications  with  explicit  access  to  a  synchronized  clock. 
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utilizing  the  portable  standard  interfaces  provided  in  IEEE  1003.1b  (incorporated  in  ISO  9945- 
1:1996). 

When  several  applications  are  executed  simultaneously,  problems  may  occur  when  remote 
application  components  are  out  of  time  synchronization  with  each  other.  DCE  takes  care  of  this 
by  synchronizing  all  the  host  clocks  on  the  system  through  its  DTS. 

One  compcncnt  of  the  DTS  clerk  reads  the  clocks  for  a  certain  time  interval  on  each  of  the  host 
machines  through  software  called  the  DTS  server.  The  DTS  clerk  then  computes  the  midpoint 
between  all  the  time  intervals  to  determine  a  new  average  time  and  resets  the  clocks  of  each  host. 
The  DTS  also  can  read  time  from  an  outside  source,  such  as  the  Universal  Coordinated  Time 
Standard  through  a  telephone  or  radio,  then  set  host  clocks  to  this  time. 

3.11.2.3.5  Related  standards.  IEEE  1003.1b  is  related  to  this  service. 

3.11.2.3.6  Recommendations.  Procurements  should  use  the  time  services  corresponding  to  the 
operating  system  being  specified  in  the  procurement.  OSF  DCE  Timing  should  be  specified  for 
distributed  systems. 
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3.11.2.4  Distributed  file  services.  (This  BSA  appears  in  part  8  and  part  1 1.)  Distributed  file 
services  (DFS)  is  a  distributed  client/server  application,  built  on  the  underlying  DCE  services.  It 
takes  full  advantage  of  the  lower-level  DCE  services  (such  as  RPC,  Security,  Threads,  and 
Directory)  and  the  distributed  computing  system.  DFS  provides  many  advantages  over 
centralized  systems.  It  provides  a  higher  availability  of  data  and  resources,  the  ability  to  share 
information  throughout  a  very  large  heterogeneous  system,  and  efficient  use  of  special  computing 
functionality.  Files  are  made  highly  available  through  replication,  or  caching,  making  it  possible  to 
access  a  copy  of  a  file  even  when  one  of  the  machines  on  which  a  file  is  stored  goes  down. 

Further,  users  are  able  to  work  with  unfamiliar  file  systems  without  having  to  know  the  unique 
commands  for  each  system. 

File  Transfer,  Access,  and  Management  (FTAM)  allows  for  the  effective  transfer,  access,  and 
management  of  different  file  types  on  remote  systems  by  creating  a  virtual  filestore  that  emulates 
the  file  services  offered  by  existing  file  service  systems. 

Remote  file  access  is  the  ability  to  access  and/or  change  a  file  type  or  content  at  a  location  other 
than  the  user's.  Remote  file  access  is  associated  with  distributed  processing/client-server 
architectures,  and  is  not  used  in  host-terminal  architectures. 

3.11.2.4.1  Standard.  Table  3.1 1-4  presents  standards  for  distributed  file  services. 


TABLE  3..1-4  Distributed  file  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSP 

DiiUibuted  Computing  Environment  (DCE)  Diftribuied 
Pile  Service  (DFS) 

DCE  1.1  DFS:1994 

Mandated 

(Approved) 

OPC 

DOD 

DoD  Standardized  Profile*  -  Pile  Trvufer,  Accees  end 
Management  (FTAM)  -  Part*  1,4,  end  5  (Reference*  ISO 
5571  peril  1-5) 

MIL-STD-2045- 

17508- Part*  1,4. 
and  5:  7/94 

Infoimatfooal 

(Approved) 

CPC 

XJOptn 

Protocol*  for  X/Open  PC  Interworking:  SMB,  Vertion  2 

C209  (10/92) 

Informational 

(Approved) 

CPC 

X/Open 

Protocol*  for  X/Opett  Interworking:  XNFS,  Iuue  4 

C218  (10/92) 

Informational  jj 
(Approved)  1 

NPC 

IEEE 

OS1  API  -  File  Trinifer,  Acceai,  end  Management  (FTAM) 
(C  Language) 

1238.1:1994 

informational  jj 
(Approved) 

NPC 

IEEE 

POSIX,  Part  1 :  Network-Traiuparent  File  Acce** 

F1003. 1  f 

Emerging  I 

(Draft)  | 

CPC 

IETF 

NFS:  Network  File  Syilem  Protocol  Specification 

RFC  1094:1989 

Informational  J 
(Not  | 

Recommended)  | 

3.1 1.2.4.2  Alternative  specification.  The  only  other  available  specifications  are  proprietary. 

3.1 1.2.4.3  Standard  deficiencies.  Limited-Purpose  File  Transfer,  Access  and  Management 
(FTAM)  subsets  do  not  provide  file  access  capabilities.  Only  Full-Purpose  FTAM  subsets  provide 
such  capabilities.  Limited-Purpose  FTAM  subsets  cannot  interoperate  fully  with  Full-Purpose 
FTAM  subsets. 
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IEEE  Transparent  File  Access  (TFA)  addresses  the  POSIX.l  refinements  needed  for  file  access, 
but  ignores  the  behavior  of  other  facilities  needed  for  file  access  between  nodes,  such  as  signals. 

The  Remote  File  System  (RFS)  is  associated  mostly  with  Unix-based  systems  rather  than  with 
heterogeneous  operating  systems  on  legacy  systems  as  the  Network  File  System  (NFS)  is. 

NFS  security  uses  the  not  very  secure  traditional  Unix  authentication  and  permissions.  Secure 
NFS  is  not  as  secure  as  it  could  be  because  it  ships  security  information  around  the  network. 

Although  the  Andrew  File  System  (AFS)  can  provide  good  networked  performance  because  it 
supports  client  caching,  this  requires  large  amounts  of  memory  and  disk  buffer  space,  as  well  as  a 
potentially  long  time  for  the  first  remotely  accessed  data  to  be  downloaded 

3.11.2.4.4  Portability  caveats.  The  SVID  provides  facilities  for  getting  file  system  information 
about  a  mounted  file  system,  but  none  of  the  SVID  functions  ("statvfsO,"  "sftatvfsO,"  and 
"ustat()")  are  compatible  with  OSF/l's  comparable  functions  ("statfsO,"  "fstatfsO,"  and  "ustatO"). 
X/Open  specifies  enhancements  to  the  "popen"  and  "pclose”  system  calls. 

Because  TFA  does  not  go  beyond  the  POSIX.l  refinements  needed  for  file  access  and  address  the 
behavior  of  other  facilities  (e.g.,  signals)  between  nodes,  a  portability  risk  exists  in  using  TFA 
between  nodes.  The  TFA  has  two  specifications,  full  TFA  (which  provides  all  of  the  file  access 
services  specified  in  ISO  9945-1)  and  Subset  TFA  (which  defines  file  access  semantics,  which  are 
less  stringent  than  POSIX  requires.  Subset  TFA  also  is  designed  for  use  with  non-P1003. 1  file 
systems.  Consequently,  it  is  possible  to  have  two  systems  compliant  with  TFA,  which  are  not 
compatible  with  each  other,  and  which  also  may  not  be  totally  compatible  with  the  core  POSIX.  1 
file  system. 

The  AFS  is  a  superset  of  NFS,  and  IEEE  TFA  is  a  superset  of  AFS  and  NFS.  Thus,  a  little 
backward  compatibility  exists  between  TFA  and  AFS  and  between  AFS  and  NFS. 

Systems  using  different  FTAM  subsets  cannot  be  assured  of  portable  applications  or 
interoperability. 

3.11.2.4.5  Related  standards.  The  following  standards  are  related  to  distributed  files  or 
distributed  file  standards: 

a.  ISO  9945- 1 : 1 996:  (POSIX.l)  System  Interfaces. 

b.  IEEE  1224:1993:  OSI  Abstract  Data  Manipulation  -  API. 

c.  IEEE  P 1 35 1 :  Association  Control  Service  Element  (ACSE)  API. 

d.  RFC  1057:  ONC  Remote  Procedure  Call  (RPC). 

e.  OSF:DCE  RPC. 

3.11.2.4.6  Recommendations.  The  OSF  Distributed  Computing  Environment  (DCE)  Distributed 
File  System  is  recommended  for  distributed  computing  environments  based  on  TCP/IP. 
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MIL-STD-2045- 17508  is  recommended  for  legacy  systems  interoperability.  Parts  1, 3,  and  6  of 
the  MIL-STD  support  only  the  Limited-Purpose  FTAM  (simple  file  transfer  and  management) 
system.  This  system  does  not  provide  file  access  capabilities.  The  MIL-STD-2045- 17508,  parts 
4  and  5  support  Full-Purpose  FTAM  (Positional  file  transfer,  simple  file  access,  and 
management))  system.  Users  requiring  remote  file  access  capabilities,  based  on  OSI  standards, 
should  use  parts  1, 4,  and  5  of  the  MIL-STD. 

An  API  to  FTAM  is  provided  by  IEEE  1238.1. 
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3.11.2.5  Distributed  directory  services.  (This  BSA  appears  in  part  4,  part  9,  and  part  1 1.)  A 
directory  or  naming  service  provides  a  standardized  naming  scheme,  a  standardized  interface  with 
the  naming  facilities,  and  the  ability  for  the  interface  to  provide  transparent  access  to  a  variety  of 
naming  schemes  and  mechanisms  (e.g.,  DCE). 

Directory  service  applications  convert  a  name  into  a  physical  address  on  a  network,  providing 
logical  to  physical  conversion.  Names  can  be  user  names,  computers,  printers,  servers,  or  files. 
This  enables  users  to  find  these  resources  without  knowing  their  locations.  The  transmitting 
station  sends  a  name  to  the  server  containing  the  naming  service  software,  which  sends  back  the 
actual  address  of  the  user  or  resource. 

3.11.2.5.1  Standards.  Table  3. 1 1-5  presents  standards  for  distributed  directory  services. 


TABLE  3.11-5  Distributed  directory  services  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Directory 

(Global  and  Cell)  Service 

DCB1.1 
Directory:  1994 

Mandated 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Session  Service  Definition 

8326:1987 

Informational 

(Approved) 

tPC 

ISO 

Open  Systems  btonxxwiectkm-Connection-Orieated 
Session  Protocol 

8327:1987 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection- Basic  Connection  Oriented 
Presentation  Service  Definition 

8822:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection -Connection -On  erued 
Presentation  Protocol 

8823:1988 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directoiy:  Models  (X-ref:  ISO  9594-2) 

X.501  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Authentication  Framework  (X-ref:  ISO 
9594-8) 

X.509,  Venion  3: 
1993 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Abstract  Service  Definition  (X-ref:  ISO 
9594-3) 

X.511 (1993) 

Infoimaiional 

(Approved) 

IPC 

ITU-T 

The  Directory:  Procedures  for  Distributed  Operation  (X- 
ref:  ISO  9594-4) 

X.518:  1993 

Infoimaiional 

(Approved) 

IPC 

ITU-T 

The  Directory:  Protocol  Specification  (X-ref:  ISO  9594-5) 

X.519 (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Selected  Attributes  Types  (X-ref:  ISO 
9594-6) 

X. 520(1993) 

Informational 

(Approved) 

IPC 

ITU-T 

The  Directory:  Selected  Object  Classes  (X-ref:  ISO  9594- 
7) 

X.521  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

TTie  Directory:  Replication  (X-ref:  ISO  9594-9) 

X.525 (1993) 

Informational 

(Approved) 

CPC' 

X/Open 

Federated  Naming:  The  XFN  Specification 

C403  (7/95) 

Informational 

(Approved) 

NPC 

IEEE 

Directory  scrvices/Name  space  API 

1224.2:1993 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Domain  None  Service  Profile  (Reference*  IAB  STD  13 
(RFC  1034,  1035)) 

MIL- STD-2045- 
17505: 1994 

Informational 

(Approved) 

3.11.2.5.2  Alternative  specification.  T  -e  are  no  alternative  specifications  available. 

3.11. 2.5  J  Standard  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.11.2.5.4  Portability  caveat .  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.11.2.5.5  Related  standards.  There  are  no  related  standards. 

3.11.2.5.6  Recommendations.  OSF  DCE  directory  services  are  recommended  for  DCE 
applications.  For  more  information  on  non-DCE  directory  services,  see  the  Host  Application 
Support  BSA  in  part  7,  Communication  Services. 
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3.10  Objects.  These  services  define  the  rules  for  creating,  deleting,  and  managing  objects. 

3.11.3.1  Object  request  broker.  (This  BSA  appears  both  in  part  8  and  in  part  1 1.)  The  Object 
Request  Broker  (ORB)  provides  a  mechanism  for  accessing  objects  anywhere  in  a  distributed 
computing  environment  It  provides  a  method  for  defining  objects  and  their  interfaces.  In 
operation,  the  ORB  provides  routing,  address  resolution,  and  authentication  services,  as  well  as 
parameter  marshaling  and  conversion  if  necessary. 

3.11.3.1.1  Standards.  Table  3. 1 1-6  presents  standards  for  object  request  brokers. 


TABLE  3.11-6  Object  request  broker  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Imm 

CPC 

OMG 

Cocanon  Object  Request  Broker  Architecture  (CORBA) 
Veflion  2.0  (includes  CORBAservices  end 
CORBAfediitie*) 

CORBA  2.0:1995 

Mandated 

(Approved) 

CPC 

XJOpm 

Common  Object  Request  Broker  Architecture  and 
Specification 

C432  (8/94) 

Informational 

(Approved) 

CPC 

X/Open 

Common  Object  Services,  Vol  1  &  2 

P432/P502 

Informational 

(Approved) 

CPC 

OMG 

Common  Object  Request  Broker  Architecture  (CORBA) 
Version  1.2,  (Same  as  X/Open  C432) 

CORBA 

Specification  Ver. 
1.2  93-12-43 

Informational 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE) 

DCE  1.1:1994 

Informational 

(Approved) 

CPC 

TOG 

Distributed  Common  Object  Model/ActiveX 

DCOM/ActiveX 

Informational 

(Draft) 

CPC 

X/Open 

Common  Object  Request  Broker  Architecture  (CORBA), 
Version  1.0  (8/92)  (Same  as  OMG  specification  91-12-1) 

P210 

Informational 

(Superseded) 

3.11.3.1.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.1 1.3. 1J  Standards  deficiencies.  At  present,  there  is  no  independent  test  for  conformance  to 
any  version  of  the  CORBA  specification. 

CORBA  1.2  (also  called  CORBA  l.X)  includes  a  standard  Interface  Definition  Language  (1DL) 
for  defining  objects.  The  IDL  is  not  the  same  as  OSF  DCE  Remote  Procedure  Call  IDL,  although 
there  are  similarities.  CORBA  1.2  also  defines  a  standard  API  for  accessing  ORB  services,  such 
as  those  needed  to  declare  that  an  object  is  available  for  use,  or  to  access  an  object. 

CORBA  1.2  does  not  include  a  specification  for  interoperability  between  ORB's,  therefore  ORB's 
from  different  vendors  are  likely  to  be  incompatible.  This  is  a  major  feature  of  the  new  CORBA 
2.0.  OMG's  CORBA  2.0  specification  allows  for  two  types  of  RPC  mechanisms:  (1)  a  mandatory 
General  Inter-ORB  Protocol  (GIOP),  and  an  optional  DCE  RPC  protocol.  ORB's  that  use 
different  methods  will  still  not  be  interoperable.  CORBA  2.0  does  not  specify  other  types  of 
distributed  computing  services  (e.g.  remote  procedure  call(RPC),  security,  directory,  time. 


April  7,  1997 


3.11-13 


Version  3.1 


Information  Technology  Standards  Guidance 


Distributed  Computing  Services 


threads,  file  system,  and  administration).  Therefore,  while  CORBA  2.0  ORBs  will  interoperate, 
higher  level  distributed  services  (security,  directory,  etc.)  may  not 

CORBA  requires  a  "mapping"  of  IDL  into  each  application  programming  language  that  is  used. 
Mappings  exist  for  C,  C++,  and  Smalltalk,  and  an  Ada95  mapping  is  under  development 

3.11.3.1.4  Portability  caveats.  Applications  developed  for  one  ORB  are  likely  to  be  portable  to  a 
different  ORB.  However,  the  lack  of  interoperability  specifications  means  that  an  object 
implemented  on  one  ORB  can  usually  not  be  accessed  from  a  different  ORB.  In  order  to  be 
interoperable,  a  system  must  select  a  single  vendor's  ORB  for  use  across  the  enterprise. 

All  vendor  claims  for  conformance  to  CORBA  2.0  should  be  matched  by  product  demonstrations 
in  the  target  environment  before  final  contract  award  is  made.  If  no  such  demonstration  is  made, 
serious  interoperability  and  security  problems  could  result,  particularly  in  multi-vendor 
environments. 

3.11.3.1.5  Related  standards.  The  following  standards  are  related  to  ORBs  or  their  standards: 

a.  Component  Integration  Laboratories  Inc.  (CILabs):OpcnDoc 

b.  Taligent  Inc.:CommonPoint 

c.  Next  Computer  Inc.:OpenStep 

3.113.1.6  Recommendations.  Users  buying  distributed  object  technology  from  multiple  vendors 
must  be  cautious.  The  use  of  ORB  technology  should  be  limited  to  pilot  projects  and  programs 
with  a  limited  number  of  sites.  If  an  ORB  is  used,  the  Object  Management  Group  (OMG) 
CORBA  (Common  Object  Request  Broker  Architecture)  Version  2.0  is  recommended.  The 
vendor  must  provide  a  plan  to  migrate  to  CORBA  2.0  with  the  DCE  RPC  as  soon  as  possible. 

The  vendor  should  also  be  required  to  state  his  proposed  solutions  to  the  other  distributed 
computing  services  listed  above,  and  to  identify  how  these  solutions  relate  to  the  distributed 
computing  services  already  in  the  user's  inventory. 

Because  of  the  lack  of  ORB  interoperability,  OSF  DCE  is  the  preferred  solution  to  distributed 
computing  requirements  in  the  near  term.  OSF  DCE  provides  the  following  distributed 
computing  services:  RPC,  security,  directory,  time,  threads,  file  system,  and  administration. 
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3.11.4  Remote  access.  These  services  support  applications  that  use  a  partitioned  database  acting 
like  a  single  coherent  database.  Also  included  are  services  for  remote  login  and  file  transfer. 

3.11.4.1  Remote  login.  (This  BSA  appears  in  part  8  and  part  1 1.)  Remote  login  is  the  ability  of 
a  user  from  a  local  machine  to  be  an  authorized  user  and  access  a  remote  machine. 

3.11.4.1.1  Standards.  Table  3.1 1-7  presents  standards  for  remote  login. 


TABLE  3.11-7  Remote  login  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

iii 

IPC 

IAB 

TELNET  Protocol 

Standard  8/RPC- 
854/RFC-855 

Mandated 

(Approved) 

IPC 

IAB 

Host  Requirements 

Standard  3/RFC- 
1122/RFC-U23 

Mandated 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection- Protocol  Specification  for 
the  Allocation  Control  Service  Element  (ACSE) 

8650:1988 

Informational 

(Approved) 

GPC 

DOD 

DoD  Standardized  Profile  -  Internet  Remote  Login  Profile 
for  DoD  Communication!  (Reference!  IAB  Sid  8  (RPC 
854  and  P°C  855  •  Telnet  Protocol:  1983)  and  IAB  Std  3 
(RPC  1123*  Requirement!  for  Internet  hone:  1989)) 

M1L-STD-2045- 

17506:7/94 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Virtual  Terminal  Bade 
Gass  Protocol 

9041:1990 

Informational 

(Approved) 

IPC 

ISO 

Open  System!  Interconnection- Bade  Connection  Oriented 
Preientation  Service  Definition 

8822:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Connection-Oriented 
Presentation  Protocol 

8823:1988 

Informational 

(Approved) 

IPC 

ISO 

Open  Systems  Interconnection-Connection-Oriented 
Session  Protocol 

8327:1987 

Informational 

(Approved) 

3.11.4.1.2  Alternative  specifications.  None 

3.11.4.1.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.11.4.1.4  Portability  caveats.  A  procurement  may  specify  Simple  Systems  or  Forms-Capable 
Systems  or  both.  However,  the  two  systems  cannot  interoperate,  and  applications  are  not 
portable  from  one  system  to  another.  Each  system  is  distinguished  by  the  VT  profile  it  supports: 
a  Simple  System  supports  the  TELNET  profile,  and  a  Forms-Capable  System  supports  the  Forms 
profile.  The  Basic  Class  VT  protocol  is  required  in  all  cases;  it  operates  independently  of  the 
Simple  or  Forms-Capable  Systems. 

3.11.4.1.5  Related  standards.  None 

3.11.4.1.6  Recommendations.  All  new  systems  and  systems  undergoing  major  upgrades  should 
use  the  Internet  Architecture  Board  (1AB)  STD  8  (RFC  854  and  855)  and  IAB  STD  3  (RFC 

1 123).  Those  persons  conducting  procurements  that  involve  IAB  standards  should  review  the 
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latest  version  of  the  IAB  official  protocol  standards  list  to  ensure  that  the  appropriate  RFCs  are 
specified. 

The  OSI  Virtual  Terminal  (VT)  standard  is  recommended  for  legacy  systems  interoperability.  A 
clear  migration  path  to  page,  scroll,  graphics,  and  mixed  mode  virtual  terminal  profiles  that  are 
being  defined  by  the  OSE  Implementors'  Workshop  (OIW)/NIST  should  be  required.  Otherwise, 
systems  capable  of  employing  only  TELNET  and  Forms  will  not  interoperate  with  future  VT 
systems.  The  "rlogin"  facilities  are  delivered  with  Berkeley  BSD-based  UNIX  operating  systems. 
Those  facilities  are  not  in  the  System  V  Interface  Definition  (SVID). 

Currently,  a  Simple  VT  and  a  Forms-Capable  VT  exist.  Few  vendors  have  implemented  a  simple 
version  of  VT.  Procurements  need  to  determine  if  Simple  or  Forms-Capable  VT  Systems  are 
sufficient  for  the  application.  No  tests  have  been  developed  for  VT  to  test  conformance.  Remote 
login  is  associated  with  distributed  processing/client-server  architectures.  It  is  not  used  in  host- 
terminal  architectures. 

No  standards  exist  for  VT  API.  A  procurement  for  a  VT  final  system  must  include  a  vendor's 
offering  of  virtual  terminal  API.  This  API  should  accommodate  as  many  VT  types  as  possible. 
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3.11.4.2  Remote  date  access.  (This  BSA  appears  in  part  4  and  part  1 1.)  RDA  specifications  are 
extensions  of  a  data  access  (RDA)  language  to  allow  remote  access  to  a  database  in  a  client- 
server  environment  RDA  refers  to  the  interfaces,  protocols,  and  formats  needed  to  allow  remote 
database  access  in  a  client-server  environment  where  the  databases  may  be  heterogeneous  and 
from  multiple  vendors. 

3.11.4.2.1  Standards.  Table  3.11-8  presents  standards  for  remote  data  access. 


TABLE  3.11-8  Remote  data  access  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

ill 

IPC 

ISO/IEC 

OSI  Remote  Daub e*e  Acceu  (RDA),  Put  1:  Generic 
Model,  Service  and  Protocol 

9579-1:1993 

Adopted 

(Approved) 

IPC 

ISO/EC 

OSI  Remote  Dalabaae  Acceu,  Pert  2:  SQL  Specialization 

9579-2:1993 

Adopted 

(Approved) 

CPC 

XJOpm 

Date  Management:  SQL  Remote  Databaae  Acceu 

Informational 

(Approved) 

CPC 

X/Open 

Date  Management:  SQL  Celt  Level  Interface  (CLI) 

C451  (4/95) 
(Supersedes  P303) 

Informational 

(Approved) 

CPC 

SAG 

Oatahatc  Language  SQL,  Acceu  Formate  A  Protocol* 
(PAP)  Specification:  1991  (Bated  on  SQL) 

SQL  Acceu  FAP 
Speca:1991 

Informational 

(Approved) 

CPC 

SAG 

DeUbaae  Language  SQL  Cell  Level  Interface  (CLI) 

SQL-89 

Informational 

(Approved) 

3.11.4.2.2  Alternative  specifications.  The  only  other  available  specifications  arc  proprietary. 

3.1 1.4.2 .3  Standards  deficiencies.  RDA  specifies  the  service  and  protocol  between  only  a  single 
client  and  server.  This  is  one  reason  that  caused  the  formation  of  the  SAG  to  put  more  distributed 
functionality  into  RDA.  RDA  does  not  consider  multiple  connections  and,  therefore,  does  not 
specify  distributed  database  access.  APIs  and  Ada  bindings  to  the  RDA  standards  are  not  defined. 

RDA  is  aligned  closely  with  the  SQL-2  Entry  Level.  However,  the  integrity  enhancement  is 
optional.  Also,  RDA  is  not  aligned  currently  with  the  FIPS  127-2  Transition  Level,  which  the 
NIST  considers  very  important  for  SQL  use. 

The  ISO  RDA  and  CLI  are  only  a  subset  of  the  SAG's  RDA  and  CLI. 

3.11.4.2.4  Portability  caveats.  RDA's  use  of  ISO  Remote  Operations  Service  Elements  (ROSE) 
hinders  precision,  adds  needlessly  to  the  text  and  Abstract  Syntax  Notation  (ASN).l,  and 
incorporates  assumptions  that  limit  the  usefulness  of  RDA.  Furthermore,  an  implementation 
conforming  to  ISO  9545  (the  OSI  standard  that  refines  the  basic  OSI  Reference  Model  to  provide 
a  framework  for  coordinating  the  development  of  existing  and  future  application  layer  standards) 
could  not  use  ROSE,  since  they  both  claim  to  be  application  service  elements. 
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RDA's  optional  integrity  enhancement  and  the  lack  of  alignment  with  the  FIPS  127-2  Transition 
Level  can  result  in  differences  among  systems  compliant  with  RDA  that  impede  portability  and 
interoperability. 

3.11.4.2.5  Related  standards.  The  following  standards  are  related  to  remote  data  access  or 
remote  data  access  standards: 

a.  ISO  9072:  ROSE 

b.  ISO  9075:1992:  SQL  Third  Edition  (same  as  NIST  FIPS  PUB  127-2:1993) 

c.  ISO  10026-1. .3:  Distributed  Transaction  Processing  Model,  Service,  &  Protocol 

d.  ANSI  X3.135-1989:  SQL 

e.  ANSI  X3. 168- 1989:  Embedded  SQL 

f.  X/Open  C193:  Distributed  TP:  The  XA  Specification 

3.11.4.2.6  Recommendations.  The  first  choice  for  a  standard  would  be  RDA,  ISO  9579,  and 
RDA:  SQL  Specialization,  ISO  9579-2,  unless  the  additional  functionalities  provided  by  the  SAG 
are  needed. 

Where  RDA  lacks  desired  capabilities  for  a  procurement,  consider  SQL  Access  Formats  and 
Protocols  Specifications  or  the  X/Open  RDA.  The  SAG  and  X/Open  are  tracking  the  RDA 
standard  and  both  support  RDA  extensions  that  are  being  adopted  by  the  emerging  RDA 
standard.  Consider  the  X/Open  specified  ASN.  1  replacement  module  that  eliminates  the  use  of 
ROSE. 
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3.11.4 .3  File  transfer.  File  transfer  is  a  service  that  provides  transmission  of  a  variety  of  file 
types  across  electronic  media. 

MIL-STD-2045- 17508  uses  OSI FTAM,  Association  Control  Service  Element  (ACSE), 
presentation,  and  session  protocols  as  base  standards.  The  FTAM  standards  specify  services  and 
protocols  for  three  different  types  of  software  file  activities.  The  File  Transfer  portion  of  the 
standard  supports  bulk  file  transfer  between  networked  systems.  The  File  Access  portion  of  the 
standard  allows  users  to  retrieve  and  update  one  record  at  a  time  from  the  middle  of  a  file,  to  add 
or  insert  a  record  into  die  file,  and  to  delete  files.  The  File  Management  portion  of  the  standard 
allows  users  to  create  new  files  and  fib  attributes,  to  inspect  and  change  the  properties  of  a  file, 
and  to  handle  the  naming  of  files.  In  addition,  the  protocol  manages  file  ownership  functions  such 
as  who  has  access  rights  to  read,  write,  or  modify  a  file. 

3.11.4.3.1  Standards.  Table  3.1 1-9  presents  standards  for  file  transfer. 


TABLE  3.11-9  File  transfer  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status. 

Doll 

(Lifecycle) 

[PC 

IAB 

Hoal  Requirements 

Standard  3/RFC- 
1122/RFC-1123 

Mandated 

(Approved) 

IPC 

1AB 

TELNET  Protocol 

Standard  8/RPC- 
854/RFC-855 

Mandated 

(Approved) 

IPC 

IAB 

Pile  Twufer  Protocol 

Standard  9/RFC- 
959 

Mandated 

(Approved) 

CPC 

IETF 

Network  Time  Protocol  (V3) 

RFC  1305:1992 

Mandated 

(Approved) 

CPC 

IETF 

Hypertext  Transfer  Protocol  •-  HTTP/1.0 

RFC  1945:1996 

Mandated 

(Approved) 

GPC 

DOD 

ACP 123  US 
Supplement  No.  1 

Mandated 

(Approved) 

IPC 

ITU-T 

The  Directory  -  Overview  of  Concepts,  Models  and 
Services  -  Dels  Communication  Networks  Directory,  1993 

X.500 

Mandated 

(Approved) 

GPC 

DOD 

MIL-STD-2045- 

47001 

Mandated 

(Approved) 

3.11.4.3.2  Alterm.'ive  specifications.  Alternative  specifications  are  unknown. 

3.11.4.3.3  Standards  deficiencies.  No  deficiencies  have  been  identified  in  the  existing  standards. 

3.11.4.3.4  Portability  caveats.  Systems  using  different  FTAM  subsets  cannot  be  assured  of 
portable  applications  or  interoperability. 

3.11.4.3.5  Related  standards.  None 
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3.11.4.3.6  Recommendations.  New  acquisitions  requiring  file  transfer  services  should  use 
Internet  Architecture  Board  (LAB)  standard  9  and  LAB  standard  3.  The  LAB  standard  9  should  be 
implemented  with  Store  unique  (STOU)  and  Abort  (ABOR)  command  mandated  on  reception. 
The  LAB  standard  3  updates  the  LAB  standard  9  by  correcting  errors  in  the  protocol  specification. 

MLL-STD-2045- 17504  and  MIL-STD-2045- 17508  and  TFTP  are  recommended  for  legacy 
systems  interoperability.  The  MIL-STD-2045-17508,  parts  1, 3  and  6  support  only  the  Limited- 
Purpose  FTAM  (simple  file  transfer  and  management)  system.  They  do  not  support  the  Full- 
Purpose  FTAM  (positional  file  transfer,  simple  file  access,  and  management)  system.  Users 
requiring  the  Full-Purpose  FTAM  system  also  should  use  parts  4  and  5  of  the  MIL-STD-2045- 
17508.  These  parts  are  identical  to  parts  4  and  5  of  the  International  Standardized  Profile  (ISP) 
10607. 

MIL-STD-2045- 14503,  Internet  Transport  Service  Supporting  OS1  Applications,  specifies  a 
standard  for  the  operation  of  OSI  applications  over  TCP/IP.  It  uses  RFC  1006,  ISO  Transport 
service  on  top  of  the  TCP,  Version  3,  as  one  of  its  base  standards.  Implementations  requiring  use 
of  MIL-STD-2045-17508  over  TCP/IP  should  use  MIL-STD-2045-14503.  An  application  level 
gateway  will  be  necessary  for  interoperation  between  systems  implementing  MIL-STD-2045- 
17508  and  systems  implementing  MIL-STD-2045- 17504  or  FTP.  The  Internet  Engineering 
Steering  Group  has  approved  the  Internet  draft  FTP-FTAM  Gateway  Specification. 

If  recommended  standards  do  not  meet  system  requirements,  or  are  cost  prohibitive,  standards 
from  the  legacy  systems  use  may  be  used  as  long  as  interoperability  is  not  impacted.  The  use  of 
legacy  standards  may  require  a  waiver  from  the  appropriate  authority.  Those  persons  conducting 
procurements  that  involve  FTP  should  review  the  latest  version  of  the  Internet  Architecture  Board 
(IAB)  official  protocol  standards  list  to  ensure  that  the  appropriate  Request  For  Comments 
(RFCs)  are  specified. 

The  DOD  is  developing  a  file  and  record  transfer  protocol  to  meet  the  specific  requirements  for 
resource  constrained  environments.  The  Unix-Unix  Communications  Protocol  (UUCP)  permits 
file  iransfer  between  two  UNIX-based  systems  via  a  dial-up  connection.  Kermit,  Xmodem,  and 
Zmodem  are  other  dial-up  file  transfer  protocols. 


April  7,  1997 


3.11-20 


Version  3.1 


Information  Technology  Standards  Guidance 


DutribulaLComputing  Services 


3.11.5  Distributed  computing  security.  Security-oriented  services  protect  the  information, 
components,  and  mechanisms  of  the  information  system.  Use  and  compliance  with  the  security 
standards  identified  in  this  document  do  not  constitute  authorization  to  process  classified  data. 
DoD  policy  covering  the  accreditation  process  must  still  be  adhered  to  in  order  to  obtain  approval 
for  the  processing  of  classified  data. 

3.11.5.1  System  access  control.  (This  BSA  appears  in  part  4,  part  9,  part  10,  and  part  1 1 .) 
System  access  control  standards  provide  high-level  guidance  on  access  control  frameworks  and 
implementation. 

3.11.5.1.1  Standards.  Table  3.1 1-10  presents  standards  for  system  access  control. 


TABLE  3,11-10  System  access  control  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Hie  DOD  Trusted  Computer  Systems  Evaluation  Criteria 

DOD  5200.28- 
STD:  1985 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Services 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

7498-2:1989 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Common  Management  Information  Services  (CMIS) 
Definition,  with  Amendment  4:  Accost  Control 

9595:1991/ 

AM4:1992 

Informational 

(Approved) 

IPC 

ISO/IEC 

ibbbssbhi 

10164-9:1995 

Informational 
(Approved)  | 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 
(Draft)  | 

IPC 

ISO/IEC 

OSI  Security  Frameworks  in  Open  Systems,  Part  3:  Access 
Control 

10181-3 

Informational  U 

(Draft)  I 

3.11.5.1.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.11.5.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.11.5.1.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.11.5.1.5  Related  standards.  The  following  guidelines  support  the  TCSEC  standard: 

a.  NCSC-TG-003,  Version  1,  September  1987,  A  Guide  to  Understanding 
Discretionary  Access  Control  in  Trusted  Systems 

b.  NCSC-TG-028,  Version  1,  May  1992,  Assessing  Controlled  Access  Protection 
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c.  NCSC-TG-020-A,  August  1989,  Trusted  UNIX  Working  Group  (TRUSIX) 
Rationale  for  Selecting  Access  Control  List  Features  for  the  UNIX  System 

3.11.5.1,6  Recommendations.  The  mandated  standards  are  recommended. 
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3.11.5.2  Entity  authentication.  (This  BSA  appears  in  part  8,  part  9,  part  10,  and  part  1 1 .) 
Entity  authentication  standards  address  data,  processes,  systems,  and  enterprises. 

3.11.5.2.1  Standards.  Table  3. 1 1-1 1  presents  standards  for  entity  authentication. 


TABLE  3.11-11  Entity  authentication  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

min 

GPC 

DOD 

The  DOD  Tnirted  Computer  Systems  Evaluation  Criteria 

Mandated 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Security 
Service* 

DCE  1.1  Security 
Services:  1994 

Mandated 

(Approved) 

GPC 

NIST 

Computer  Data  Authentication 

FIPS  PUB 
113:1985 

Informational 

(Approved) 

GPC 

NIST 

Entity  Authentication  Using  Public  Key  Ciyptography 

FIPS  PUB 
196:1996 

Emerging 

(Approved) 

CPC 

OSF 

Distributed  Computing  Environment  (DCE)  Rev.  1.2.2 

DCE  Rev. 
1.2.2:1996 

Informational 

(Approved) 

IPC 

ISO 

Fuoncul  Transactions  -  Retail  Banking  Security 
Requirements  for  Message  Authentication 

9807 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  Mechanisms -  Part  1:  General  Model 

9798-1:1991 

Infoi  uional 
(Aj  oved) 

IPC 

ISO 

Entity  Authentication  Mechanisms  •  Part  3:  Entity 
Authentication  Using  a  Public  Key  Algorithm 

9798-3:1993 

Informational 

(Approved) 

GPC 

NIST 

Guideline  for  Use  of  Advanced  Authentication  Technology 
Alternatives 

FIPS  PUB 
190:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  2:  Mechanisms  Using 
Symmetric  Encipherment  Algorithms 

9798-2:1994 

Informational 

(Approved) 

IPC 

ISO 

Entity  Authentication  -  Part  4:  Mechanisms  Using  a 
Cryptographic  Check  Function 

9798-4:1995 

Informational 

(Approved) 

CPC 

X/Open 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020:  1990 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

CPC 

IETF 

The  Kerberos  Network  Authentication  Service  (V5) 

RFC  1510:1993 

Informational 

(Draft) 

IPC 

ISO 

Entity  Authentication  Mechanisms,  Part  5:  Entity 
Authentication  Using  Zero  Knowledge  Techniques 

9798-5:1993 

Informational 

(Draft) 

3.11.5.2.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.11.5.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.11.5.2.4  Portability  caveats.  OSF  DCE  Version  1.1's  authentication  service  is  based  on 
Kerberos  Version  5  (RFC  1510),  but  is  not  totally  compatible  with  RFC  1510.  DCE  1.2.2  adds 
testing  and  official  support  for  Kerberos  Version  5. 
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3.1 1 .5.2.5  Related  standards.  The  following  stan< '  lrds  are  related  to  entity  authentication: 

a.  DOD  NCSC-TG-017,  Version  1,  September  1991,  Guide  to  Understanding 
Identification  and  Authentication  in  Trusted  Systems. 

b.  FIPS  PUB  196, 1 1  October  1996. 

FIPS  PUB  196  becomes  effective  6  April  1996.  It  is  based  on  ISO/IEC  9798- 
3:1993  and  specifies  two  challenge-response  protocols  by  which  entities  in  a 
computer  system  may  authenticate  their  identities  to  one  another.  FIPS  PUB  196 
is  for  use  in  public  key  based  challenge-response  and  authentication  systems  at  the 
application  layer  within  computer  and  digital  telecommunications  systems. 

3.11.5.2.6  Recommendations.  The  mandated  standards  are  recommended. 
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3.11iJ  Security  audit  (This  BSA  appears  in  part  7,  part  9,  part  10,  and  part  11.)  Security 
auditing  is  a  review  or  examination  of  records  and  activities  to  test  controls,  ensure  compliance 
with  policies  and  procedures,  detect  breaches  in  security,  and  indicate  changes  in  operation 
(paraphrased  from  ISO  7498-2). 

3.ILSJ.1  Standards.  Table  3.1 1-12  presents  standards  for  security  audit 


TABLE  3,11-12  Security  audit  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

The  DOD  Trusted  Computer System*  Evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

CPC 

NMF 

OMNIPoint  1  (Adopt*  ISO  Profile  SeU  1 1 183-X,  12059- 
X,  end  12060-X,  include!  ISO/IEC  10I64-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systeau  Management,  Part  8:  Security  Audit  Trail 
Function  (same  as  ITU-T  X.740) 

10164-8:1993 

Informational 

(Approval) 

CPC 

X/Open 

Security  Interface  Specification:  Auditing  and 
Authentication 

S020:  1990 

Informational 

(Approved) 

IPC 

CCEB 

Common  Criteria  for  Information  Technology  Security 
Evaluation,  (CC)  Version  1.0 

CC  Version  1.0: 
1996 

Emerging 

(Draft) 

IPC 

ISO/IEC 

OSI  Security  Frameworks  for  Open  Systems,  Part  7: 
Security  Audit  Framework 

10181-7 

Informational 

(Draft) 

IPC 

ISO/IEC 

OSI  Distributed  Transaction  Processing  (DTP)  •  Draft 
Amerxhnents  to  Paiti  1-3:  Transaction  Processing  Security 

WDAMs  ((SC21 
N6232)  to  ISO 
10026-1.2.3)  1994 

Informational 

(Draft) 

3.11.5 .3.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.1 1.5.3 .3  Standards  deficiencies.  ISO  Transaction  Processing  Security  work  (WDAMs  to  ISO 
10026-1,2,3)  is  in  the  early  stages.  Its  content  is  not  defined,  and  it  cannot  be  used  for 
procurement.  ISO  10164-8  does  not  define  a  security  audit,  or  explain  how  to  perform  one.  It 
does  not  define  implementation  aspects,  occasions  where  the  use  of  the  security  audit  trail 
function  is  appropriate,  or  the  services  necessary  for  the  establishment  and  normal  or  abnormal 
release  of  a  management  association. 

There  is  a  need  for  a  standard  for  programming  and  interfaces  to  support  development  of  portable 
tools  for  audit  trail  analysis  and  configuration. 

3.11.5.3.4  Portability  caveats.  Proposed  amendments  to  ISO  10026  have  ceased.  This  is  a  high 
portability  risk  area. 

3.11.5.3.5  Related  standards.  The  following  guidelines  support  theTCSEC  standard: 
a.  NCSC-TG-005,  Version  I,  July  1987,  Trusted  Network  Interpretation 
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b.  NCSC-TG-011,  Version  1, 1  August  1990,  Trusted  Network  Interpretation 
Environments  Guideline  -  Guidance  for  Applying  the  Trusted  Network 
Interpretation 

c.  NCSC-TG-001,  Version  2,  June  1988,  A  Guide  to  Understanding  Audit  in  Trusted 
Systems 

3.11.5.3.6  Recommendations.  The  mandated  standard  is  recommended. 
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3.11.5.4  Distributed  computing  security  labeling.  (This  BSA  appears  both  in  part  10  and  part 
11.)  Distributed  computing  security  labeling  provides  a  security  labeling  service  to  support 
mandatory  access  controls  within  a  distributed  environment 

3.115.4.1  Standards.  Table  3.1 1-13  presents  standards  for  distributed  computing  security 
labeling. 


TABLE  3.11-13  Distributed  computing  security  labeling  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

DOD 

The  DOD  Trusted  Computer  Systems  evaluation  Criteria 

DOD  5200.28- 

STD:  1985 

Mandated 

(Approved) 

GPC 

DOD 

Truned  Database  Management  System  Interpretation  of  the 
Trusted  Computer  Systems  Evaluation  Criteria 

NCSC-TG-021, 
Vereion  1: 1991 

Mandated 

(Approved) 

GPC 

DOD 

Compertmented  Mode  Woriutation  (CMW)  Evaluation 
Criteria 

DDS-2600-6243* 

92 

Informational 

(Approved) 

GPC 

DOD 

DDS-2600-6243- 

91 

Informational 

(Approved) 

GPC 

DOD 

CMW  Labeling:  Encoding  Format 

Informational 

(Approved) 

IPC 

ISO 

7498.2:1989 

Informational 

(Approved) 

3.11.5.4.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.11.5.4.3  Standards  deficiencies.  The  subjects  and  objects  requiring  security  labeling  in  a 
distributed  computing  environment  have  not  been  standardized  or  identified  in  any  standardized 
framework. 

3.115.4.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.11.5.45  Related  standards.  DOD  5200. 1-R,  "Information  Security  Program  Regulation,"  June 
1986,  establishes  DOD  policy  for  security  classification,  declassification,  and  marking  of  DOD 
information.  It  also  contains  DOD  policy  for  safeguarding  of  classified  information,  including 
accountability,  storage,  transmission,  and  destruction  of  the  information. 

3.11.5.4.6  Recommendations.  The  mandated  standards  are  recommended. 

The  DGSA  (TAF1M  Volume  6)  provides  general  architectural  guidance  for  information  domains 
which  can  exist  in  a  distributed  environment.  The  properties  of  information  domains  share  some 
similarities  with  security  labels  in  a  distributed  environment 
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3.115.5  Data  encryption  security.  (This  BSA  appears  in  part  5,  part  7,  part  10,  and  part  1 1 .) 
Encryption  is  the  cryptographic  transformation  of  data  to  produce  cipher  text  Standards  for  data 
encryption  security  services  describe  services  such  as  definitions/algorithms,  modes  of  operation, 
and  guidelines  for  use  for  those  systems  that  require  their  data  to  be  encrypted  using  data 
encryption  security  services.  None  of  these  standards  are  for  systems  processing  classified 
information. 

3.1155.1  Standards.  Table  3. 1 1-14  presents  standards  for  data  encryption  security. 


TABLE  3.11-14  Data  encryption  security  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Escrowed  Encryption  Standard  (EES) 

FIPS  PUB  185: 
1994 

Mandated 

(Approved) 

OPC 

NIST 

Data  Encryption  Standard  (DES)  (related  to  ANSI  X3.92- 
1981/R1987/R1993) 

FIPS  PUB  46- 
2:1993  (Reaffirmed 
until  1998) 

Informational 

(Approved) 

GPC 

NIST 

Guideline*  for  Implementation  and  uiing  the  NBS  Data 
Encryption  Standard 

FIPS  PUB  74:1981 

Informational 

(Approved) 

GPC 

NIST 

Data  Encryption  Standard  (DES)  Mode*  of  Operation 
(related  to  ANSI  X3. 106- 1983) 

FIPS  PUB  81:1980 

Informational 

(Approved) 

GPC 

NIST 

Security  Requirement*  for  Cryptographic  Module* 

FIPS  PUB  140- 
1:1994 

Informational 

(Approved) 

IPC 

ISO 

Mode*  of  Operation  for  a  64-Bit  Block  Cipher  Algorithm 
(Related  to  ANSI  X3. 106) 

8372:1987 

Informational 

(Approved) 

NPC 

ANSI 

Data  Encryption  Algorithm 

X3. 92-1981 
(RI993) 

Informational 

(Anxoved) 

NPC 

ANSI 

Digital  Encryption  Algorithm  -  Mode*  of  Operation 

X3. 106-1983 
(RI990) 

Informational 

(Approved) 

GPC 

NIST 

Advanced  Encryption  Standard 

FIPS  PUB  JJJ 

Informational 

(Formative) 

3.1155.2  Alternate  specifications.  The  only  other  available  specifications  are  proprietary,  for 
example,  RSA. 

3.11.5.5.3  Standards  deficiencies.  Deficiencies  i>.  the  existing  standards  are  unknown. 

3.11.5.5.4  Portability  caveats.  DES  applications  are  not  interoperable  with  non-DES  systems. 
Portability  problems  related  to  EES  are  unknown.  The  U.S.  controls  export  of  cryptographic 
technologies,  products,  and  related  technologies  as  munitions.  On  October  1 ,  1996,  a  new  federal 
policy  allowing  U.S.  vendors  to  export  products  using  up  to  56-bit  encryption,  provided  the 
vendors  sign  an  agreement  to  make  their  56-bit  encryption  technologies  key-recovery-compliant 
within  24  months. 

3.11.5.55  Related  standards.  FIPS  PUB  1 13,  Computer  Data  Authentication,  is  related  to  DES 
security  mechanisms  and  their  standards. 
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3.11  .5.5.6  Recommendations.  The  mandated  standard  is  recommended.  FIPS  PUB  185,  EES, 
supports  lawful  authorized  access  to  the  keys  required  to  decipher  enciphered  information  for 
systems  requiring  strong  encryption  protection  of  sensitive  but  unclassified  information.  EES 
provides  stronger  protection  than  DES  against  unauthorized  access.  Devices  conforming  to  EES 
may  be  used  when  replacing  Type  II  and  Type  HI  (DES)  encryption  devices  owned  by  the 
Government  Implementations  requiring  use  of  EES  should  require  conformance  with  FIPS  PUB 
140-1. 


On  2  January  1997,  NIST  announced  plans  to  develop  a  FIPS,  Advanced  Encryption  Standard, 
incorporating  an  advanced  encryption  algorithm  to  replace  DES  (FIPS  PUB  46-2). 
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3.11.5.6  Systems  non-repudiation.  (This  BSA  appears  in  part  5,  part  7,  part  10,  and  part  1 1 .) 
These  standards  provide  the  security  services  for  non-repudiation  in  systems. 

3.11.5.6.1  Standards.  Table  3.1 1-15  presents  standards  for  systems  non-repudiation. 

TABLE  3.11-15  Systems  non-repudiation  standards 


Standard 

Reference 


Standard 

Type 

Sponsor 

GPC 

FIST 

GPC 

DOD 

GPC 

NSA 

GPC 

NSA 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO 

CPC 

IETF 

CPC 

OMG 

CPC 

IETF 

IPC 

ISO/IEC 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO 

Digital  Signature  Standard  (DSS) 


Information  Technology  -  De/eoae  Standardized  Profile*  MIL- STD- 2045- 

AMHXn(D)-  Menage  Handling  Systems  -  Meaaage  18500:  1993 

Security  Protocol  (MSP)  Parts  1-5 


Message  Security  Protocol  (MSP) 


Message  Security  Protocol  (MSP) 


SDN.701,  Rev.  3.0: 
1994 


SDN.701.  v.  4.0. 
Rev.  A:  1997 


Generic  Upper  Layer  Security  (GULS)- Part  1:  Overview,  11586-1:1994 
Models,  and  Notation 


Generic  Upper  Layer  Security  (GULS) -Part  4:  Protecting  11586-4:1994 
Transfer  Syntax  Specification 


7498-2:1989 


RFC  1826: 1995 


IP  Authentication  Header  (AH) 


Common  Object  Request  Broker  Architecture  (CORBA)  OMG95-12-1: 


S/MIME  Message  Specification:  PKCS  Security  Services 
for  MIME 


Repudiation  (same  as  ITU-TS  X.813) 


Non-Repudiation  Mechanisms  Part  I:  General  Model 


Non-Repudiation  Mechanisms  Pnrt  2:  Using  Symmetric 
Encipherment  Algorithms 


Non-Repudiation  Mechanisms  Patt  3:  Using  Asymmetric 
Techniques 


OSI  Distributed  Transaction  Processing  (DTP)  -  Draft  WDAMs  (SC21  N  Informational 


Amendments  to  Parts  1  to  3:  Transaction  Processing 
Security 


5232  to  ISO 
10026-1,2.3)  1991 


Informational 

(Draft) 


Informational 

(Draft) 


3.11.5.6.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.11.5.6.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
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3.11.5.6.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.11.5.6.5  Related  standards.  FIPS  PUB  180-1,  Secure  Hash  Standard,  must  be  used  with  FIPS 
PUB  186.  FIPS  PUB  180-1  provides  the  Secure  Hash  Algorithm  used  in  generating  and  verifying 
electronic  signatures. 

3.11 .5.6.6  Recommendations.  The  mandated  standards  are  recommended  for  non-repudiation. 

MIL-STD-2045- 18500  describes  the  sc.'  irity  provided  by  MSP.  It  should  be  used  for  DOD 
message  systems  that  are  required  to  exchange  classified  and  sensitive  but  unclassified 
information.  It  is  based  on  Version  3.0  of  the  MSP  documented  in  SDN.701,  "Secure  Data 
Network  System  (SDNS)  Message  Security  Protocol,"  Revision  1.5,  1  August  1989.  MSP  is 
under  revision  to  Version  4.0  to  accommodate,  in  part,  Allied  requirements.  This  DSP  standard 
will  be  replaced  by  a  portion  of  the  U.S.  Supplement  to  ACP  123  or  ACP  120,  Common  Security 
Protocol,  when  the  revision  to  MSP  is  complete. 

MSP  provides  for  signed  receipts.  S/MIME,  an  Internet  Draft  specification,  does  not  provide  for 
signed  receipts. 
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3.11.5.7  Security  alarm  reporting.  (This  BS A  appears  in  part  7,  part  9,  part  10,  and  part  1 1 .) 
Security  alarm  reporting  is  the  capability  to  receive  notifications  of  security-related  events,  alerts 
of  any  misoperations  in  security  services  and  mechanisms,  alerts  of  attacks  on  system  security,  and 
information  as  to  the  perceived  severity  of  any  misoperation,  attack,  or  breach  of  security. 

3.115.7.1  Standards.  Table  3.11-16  presents  standards  for  security  alarm  reporting. 


TABLE  3.11-16  Security  alarm  reporting  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

NMF 

OMNIPmnt  1  (AdopU  ISO  Profile  S«u  11183-X,  12059- 
X,  and  12060- X,  include*  ISO/IEC  10164-X) 

OMNIPoint  1:1993 

Informational 

(Approved) 

IPC 

ISO/IEC 

OSI  Systems  Management,  Part  7:  Security  Alarm 
Reporting  Function  (same  as  ITU-T  X.736) 

10164-7:1992 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB  179- 

1:1995 

Informational 

(Approved) 

GPC 

NIST 

Government  Network  Management  Profile  (GNMP) 

FIPS  PUB 
179:1992 

Informational 

(Superseded) 

3.11.5.7.2  Alternate  specifications.  There  are  no  alternative  specifications. 

3.11.5.73  Standards  deficiencies.  FIPS  PUB  179-1  supersedes  FIPS  PUB  179.  ISO  10164-7 
does  not  define  implementation  aspects,  specify  the  manner  in  which  management  is  accomplished 
by  the  user  of  the  Security  Alarm  Reporting  Function  (SARF),  define  interactions  that  result  in 
the  use  of  the  SARF,  or  specify  the  services  necessary  for  the  establishment  and  normal  and 
abnormal  release  of  a  management  association. 

3.11.5.7.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.11.5.75  Related  standards.  There  are  no  related  standards. 

3.11.5.7.6  Recommendations.  There  are  no  recommended  standards  for  security  alarm 
reporting. 
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3.12  Multimedia.  For  purposes  of  this  part  of  the  ITSG,  multimedia  is  defined  as:  "Two  or 
more  media  types  (audio,  video,  imagery,  text,  and  data)  electronically  manipulated,  integrated, 
and  reconstructed  in  synchrony."  This  definition  was  developed  by  the  Interactive  Multimedia 
Association  (IMA).  Part  12  covers  multimedia  data  interchange,  programming  environments  and 
systems,  presentation,  and  multimedia  aspects  of  video  and  audiographic  teleconferencing. 

By  definition,  multimedia  encompasses  a  broad  range  of  media  types  and  associated  standards. 
Because  multimedia  is  an  emerging  technology,  many  related  standards  are  industry-based  de 
facto  standards  or  emerging  official  standards.  Therefore,  as  a  general  rule,  any  procurement 
involving  multimedia  should  proceed  with  caution  in  standards  selection  and  ensure  that  selected 
standards  are  compatible.  Often,  interim  solutions  may  be  required  to  meet  immediate  mission 
requirements.  Therefore  original  source  materials  should  always  be  maintained  for  archival  and 
re-use  purposes. 

The  first  step  in  selecting  and  adhering  to  the  right  multimedia  standards  is  assuring  that  end- 
users,  designers,  ana  acquisition  staff  have  a  clear  vision  of  what  the  final  product  must  do.  The 
DOD  model  for  process  definition  is  the  Integration  Definition  (IDEF)  process.  Through  it, 
process  owners  and  decision  makers  can  visualize  how  selected  technologies  will  enhance  the  core 
operation.  Following  the  process  through  the  steps  in  the  model  helps  assure  sufficient  vision, 
imagination,  and  scope  have  gone  into  the  project  This  increases  the  likelihood  that  the 
multimedia  solution  meets  as  many  of  the  present  and  planned  mission  requirements  as  possible. 

It  also  demonstrates  when,  where,  and  to  what  degree  multimedia  standards  apply. 

Multimedia  standards  apply  differently  according  to  the  types  of  products  or  services  required  and 
the  individual's  role  in  the  process.  However,  regardless  of  how  wide  or  narrow  the  frame  of 
reference,  understanding  the  multimedia  principles  of  portability,  interoperability,  and 
interchangeability  will  help  achieve  the  ultimate  goal  of  compatibility  to  the  maximum  extent 
possible. 

Portability  means  software  (e.g.,  a  multimedia  application  or  title)  can  run  without  regard  to 
system  hardware,  operating  system,  mode  (stand-alone,  network,  distributive,  mainframe-to- 
terminal,  etc.),  or  peripheral  equipment.  Measures  of  portability  attempt  to  express  the  ease  of 
operating  a  piece  of  software  on  different  automated  systems.  The  more  portable  the  application 
development  environment,  the  more  likely  that  a  favorite  application  is  available  to  the  end-user's 
favorite  platform. 

(NOTE:  For  purposes  of  part  12,  a  multimedia  title  is  a  finished  multimedia  production  for 
presentation  to  an  end-user.) 

Interoperability  is  successful  interchange  of  both  data  and  meaning.  Application  processes 
interoperate  when  the  output  of  a  given  process  is  successfully  acquired  and  used  by  other 
processes.  Consider  an  audiographic  teleconference.  The  goal  of  the  conference  is  to  talk  about 
and  make  changes  to  a  document  that  includes  text,  graphics,  and  other  elements.  Assume  that 
the  participants  have  software  that  can  display  this  document,  but  that  each  participant  has  a 
different  brand  of  software.  If  any  participant  can  make  changes  to  the  document  that  are  then 
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displayed  to  all  paiticipants,  then  interoperability  exists.  However,  if  a  participant  must  relate 
desired  changes  to  the  conference  initiator,  who  then  makes  the  changes  and  displays  the  edited 
document  on  the  other  participants'  computers,  portability  exists  but  not  interoperability. 

General-purpose  standards  to  support  interoperability  are  usually  complex  and  comprehensive. 
Usually  such  standards  rely  on  other  standards  and  families  of  related  standards  to  provide 
interoperability. 

NOTE:  Throughout  Part  12,  all  tables  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  I  PC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3.12.1  Multimedia  data  interchange  formats  and  protocols.  Interchange  refers  to  transferring 
information  between  processes  (applications  or  services).  Interchange  can  be  successful  only  if 
both  parties  to  the  interchange  transaction,  sender  and  receiver,  know  about  the  format  of  the 
information  being  interchanged.  Interchange  can  be  blind,  which  means  that  the  information  must 
be  self-describing  to  some  extent,  or  negotiated,  which  means  that  sender  and  receiver  carry  on  a 
dialogue  to  determine  formats  they  have  in  common  and  can  interchange  successfully. 

Information  can  be  interchanged  at  several  semantic  levels.  The  simplest  level  we  will  call  a 
monomedia  format  or  data  type.  A  data  type  represents  one  type  of  information.  Multimedia 
data  types  of  interest  include  text,  vector  graphics,  raster  graphics  (still  and  moving  images),  and 
audio.  All  data  types  are  represented  in  encoded  form.  The  encoding  may  be  simple  (e.g.,  7-bit 
ASCII  text)  or  complex  (e.g.,  Moving  Picture  Experts  Group  [MPEG]  compression  and  motion 
prediction). 

Data  types  may  be  interchanged  directly  or  embedded  in  more  structured  interchange  files  or  data 
streams.  Collections  of  monomedia  objects  may  be  wrapped  in  a  container  file,  such  as  Bento 
(created  by  Apple  and  recommended  by  the  IMA).  Relationships  among  the  objects  in  these  files, 
such  as  synchronization  information,  may  be  shown  by  providing  additional  information. 

Another  layer  of  structuring  may  be  provided  by  providing  a  direct  mapping  onto  the  file  system 
of  an  operating  system.  Such  features  of  file  systems  as  directories,  subdirectories,  and  files  may 
have  direct  analogues  on  the  transmission  media  (e.g.,  tape,  floppy  disk,  or  CD-ROM). 

Data  formats  allow  interchange  of  monomedia  information.  Container  file  formats  allow 
interchange  of  information  that  is  more  structured  and  is  capable  of  showing  relationships  among 
the  data  formats.  Many  data-  and  container-format  specifications  contain  extra  information  that 
permits  some  meaning  to  be  deduced  from  the  interchange  of  formats.  Currently,  most  data 
interchange  is  accomplished  with  data  formats. 
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3.12.1.1  Text  encoding  interchange.  Text  encodings  are  methods  of  defining  characters  sets  as 
numerical  values  that  are  mapped  to  specific  characters.  This  BSA  is  a  distillation  of  the 
Characters  and  Symbols  MLSA. 

3.12.1.1.1  Standards.  Table  3.12-1  presents  multimedia  standards  for  text  interchange. 


TABLE  3.12-1  Text  encoding  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

mm 

1PC 

ISO/IEC 

msmsmsm 

10646-1:1993 

Mandated 

(Approved) 

IPC 

ISO/IEC 

ISO  8-Bit  Single-Byte  Coded  Graphic  Character  Sets:  Parti 
1-9 

8859-1  to  9:1987- 
1989 

Mandated 

(Approved) 

IPC 

ISO/IEC 

ISO  8-Bit  Single-Byte  Coded  Graphic  Character  Seta:  Part 
10:  Latin  Alphabet  Set  No.  6 

8859-10:1992 

Mandated 

(Approved) 

GPC 

NIST 

lii 

FIPS  PUB  1- 

2:1984 

Informational 

(Approved) 

CPC 

Unicode 

Consortium 

Unicode  version  1.1 

UCS-2 

Informational 

(Approved) 

GPC 

NIST 

Additional  Controls  for  Use  with  American  National 
Standard  Code  for  Information  Interchange  (adopt!  ANSI 
X3.64-  1979/R1990) 

FIPS  PUB  86:1981 

Informational 

(Approved) 

IPC 

ISO 

ISO  7-Bit  Coded  Character  Set  for  Information  Exchange 

646:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

Character  Code  Structure  and  Extension  Techniques 

2022:1994 

Informational 

(Approved) 

NPCAPC 

ANSI/ISO/IEC 

ISO  8-Bit  Code  for  Information  Interchange  -  Structure  and 
Rules  for  Implementation  (8-Bit  ASCII)  (Revision  and 
redesignation  of  ANSI  X3.134.I ) 

4873:199! 

Informational 

(Approved) 

IPC 

ISO/IEC 

Coded  Graphic  Character  Set  for  Text  Communication  - 
Latin  Alphabet  Second  Edition  (replaces  6937  ptl  &  pL  2) 

6937:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Control  Functions  for  ISO  7-Bit  and  8-Bit  Coded  Character 
Sets 

6429:1992 

Informational 

(Approved) 

CPC 

X/Open 

Universal  Multiple-Octet  Coded  Character  Set  Coexistence 
and  Migration 

E401  (3/94) 

Informational 

(Approved) 

TBD 

ns 

JlS-Japan  Unix 

JIS  X020 1/0202 

Informational 

(Approved) 

CPN-C 

AT&T 

Extended  Unix  Code  (EUC)  (ISO  2022  compliant) 

System  V 
Multinational 
Language  System 

Informational 

(Approved) 

CPN-C 

Microsoft 

Shift  -  JIS  for  PCs  and  Macs  (ISO  2022  compliant) 

■MCT 

Informational 

(Approved) 

CPC 

Unicode 

Consortium 

Unicode  Standard 

Unicode  v.  2.0 

Informations! 

(Draft) 

IPC 

ISO/IEC 

Universal  Multiple-Octet  Coded  Character  Set.  Part  1 : 
Architecture  and  Basic  Multilingual  Plane,  Amend  1:  UTF- 
16,  Amend  2:  UTE-8,  Amend  3:  control  characters.  Amend 
4:  remove  UTTM 

10646-1,  Am  1- 
4:1993 

Informational 

(Draft) 

IPC 

ISO 

Universal  Multiple- Octet  Coded  Character  Set.  Part  I : 
Architecture  and  Buie  Multilingual  Plane,  Amend  5: 
Korean  Hangul;  6:  Tibetan  additions;  8:  Han  unification 

10646-1:  DAM  5-8 

Informational 

(Draft) 
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3.12.1.1.2  Alternative  specifications.  None. 

3.12.1.1.3  Standards  deficiencies.  For  character  sets,  each  language  needs  a  programming 
environment  to  handle  conversion,  sorting,  and  string  handling  to  support  proper  localization  and 
internationalization. 

3.12.1.1.4  Portability  caveats.  Target  presentation  systems  and  viewers  may  not  have  the 
required  support  for  specific  text  encodings. 

A  backward  incompatible  change  of  ISO  10646  is  being  prepared.  It  involved  a  rearrangement  of 
the  code  positions  for  some  Korean  characters.  This  will  probably  be  in  draft  amendment  5  which 
is  expected  in  1997.  This  rearrangement  is  contrary  to  the  previous  policy  of  the  committee. 

3.12.1.1.5  Related  standards.  None. 

3.12.1.1.6  Recommendations.  ISO  8SS9  is  the  predominant  character  encoding  standard  used  in 

X  Windows  and  includes  »m  trilingual  character  set  standards.  ISO  2022  specifies  methods  of 
extending  the  255-glypi.  „•  sets  coded  by  single  octets.  ISO  10646  allows 

multiple-byte  encodings. 

Unicode  is  a  standard  for  the  representation  of  character  sets.  It  is  ISO  10646 

compliant  Unicode  uses  a  unified  Han  character  set  to  represent  Japanese  and  Chinese 
characters.  A  country-specific  implementation  may  be  required  for  each  country  if  this  system  is 
used.  Unicode  should  be  used  for  any  new  systems  for  which  will  need  large  character  sets  such 
as  those  used  in  foreign  languages. 
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3.12.1.2  Document  interchange.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  12, 
Multimedia.)  Document  interchange  standards  allow  the  transfer  of  formatted  documents  across  a 
network  so  they  can  be  reproduced  exactly  and  worked  on  at  their  destinations. 

3.12.1  M.i  Standards.  Table  3.12-2  presents  standards  for  document  interchange. 


TABLE  3.12-2  Document  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO 

Standard  Generalized  Markup  1  angtife  (SGML) 
(Amendment  I  •  1988)  (Adapted  by  FIPS  PUB  152:1989) 

8879:1986 

Mandated 

(Approved) 

CPC 

IETF 

HyperText  Markup  Language  (HTML)  v.2.0 

RFC  1866:1995 

Mandated 

(Approved) 

GPC 

DOD 

Markup  Requirements  and  Generic  Style  Specification  for 
Electronic  Printed  Output  and  Exchange  of  text  (baaed  on 
ISO  8879) 

ME-PRF-28001 

Informational 

(Approved) 

IPC 

ISO/IEC 

Distributed  Office  Appbcubooi  Model  (DO AM),  Part  1: 
General  Model 

10031-1:1991 

Informational 

(Approved) 

IPC 

ISO/tEC 

Distributed  Office  Applications  Model  (DO AM),  Part  2: 
Distinguished  Object  Reference  and  Associated  Procedures 

10031-2:1991 

Informational 

(Approved) 

IPC 

ISO/IEC 

10166-1:1991 

.iiformational 

(Approved) 

IPC 

ISO/1EC 

Document  Filing  and  Retrieval  (DFR),  Part  2:  Protocol 
Specification  (corrigendum  1-1994) 

10166-2:1991 

Informational 

(Approved) 

IPC 

ISO 

Text  and  Office  Systems  -  Referenced  Data  Transfer  -  Part 

1:  Abstract  Service  Definition 

10740-1 

Informational 

(Approved) 

IPC 

ISO 

Test  and  Office  Systems  -  Referenced  Data  Transfer  -  Part 

2:  Protocol  Specification 

10740-2 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  -  Services 
and  Protocols-  Introduction  and  General  Principles 

T.431  (1992) 

Informational 

(Approved) 

IPC 

rru-T 

Document  Transfer  and  Manipulation  (DTAM)  -  Service 
Definition 

T.432  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  •  Protocol 
Specification 

T.433  (1993) 

'-tformational 

(Approved) 

IPC 

ITU-T 

Document  Transfer  and  Manipulation  (DTAM)  - 
Operational  Structure 

T.441  (1989) 

Informational 

(Approved) 

NPC 

ANSI 

Text  Information  Interchange  in  Page  Image  Format  (PIF) 

X3.  98-1983 

Informational 

(Approved) 

IPC 

ISO 

Standard  Generalized  Markup  Language  (SGML) 
Document  Interchange  Format  Support  Facilities  (SDIF) 

9069:1988 

Informational 

(Approved) 

IPC 

ISO/IEC 

Documentation  Style  Semantics  and  Specification 
Language  (DSSSL) 

10179:1995 

Information*’. 
(Appro’  ed) 

CPN-C 

AT&T 

TROFF  •  Markup  Language 

Unix  BSD  4.3 

Informational 

(Approved) 

OPN-C 

Microsoft 

Rich  Text  Format  (RTF) 

RTF  Tech.  Manuals 

Information*! 

(Approved) 

CPN-C 

Adobe 

PostScript  Type  I  -  Outlines 

PS  Tech.  Manuals 

informational 

(Approved! 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPN-C 

Adobe 

Portable  Document  Format  (PDF) 

PDF 

Infonnabooil 

(Approved) 

CPC 

IETF 

HyperText  Mufcup  Language  (HTML) 

HTMLv.3.2 

Emerging 

(Draft) 

GPC 

DOD 

Marimp  ReqaimreoU  and  Generic  Style  Specification  for 
Electronic  Printed  Oxput  aod  Exchange  of  text  (baaed  on 
ISO  W9) 

MIL-K*  -dOOlB  of 
626/1993 

InfomuiUQil 

(Supeneded 

_ £als» _ 

3.12.1.2.2  Alternative  specifications.  The  following  specifications  are  also  available: 

a.  ANSI/NISO  Z39.59-1988  (to  represent  the  logical  structure  of  books  and  articles) 

b.  The  Association  of  American  Publishers  (AAP),  the  Text  Encoding  Initiative 
(TEI),  and  the  DOD  Continuous  Acquisition  and  Life  Cycle  Support  (CALS) 
program  have  designed  alternate  nonproprietary  architectures  with  SGML 
encodings 

c.  Microsoft's  Dynamic  Data  Exchange  (DDE) 

d.  Microsoft's  Dynamic  Link  Libraries 

e.  ANSI/NISO  Z39.2- 1 994:  information  Interchange  Format 

f.  ANSI/NISO  Z39. 18-1995:  Scientific  and  Technical  Reports  -  Elements, 
Organisation,  and  Design 

g.  ANSI/NISO  Z39.50-1992:  Information  Retrieval  Application  Service  Definition 
and  Protocol  Specification  for  Open  Systems  Interconnection 

it.  ANSI/NISO  Z39.59-1992:  Common  Command  Language  for  Online  Interactive 
Information  Retrieval 

3. 12. 1.2 -3  Standards  deficiencies.  There  is  very  little  standardization  of  font  names  when 
handling  fonts  represented  by  tagged-text  data  types.  However,  many  systems  are  attempting  font 
substitution,  that  is,  replacing  a  specified  font  with  one  that  is  similar,  such  as  substituting 
TrueType  Arial  for  PostScript  Helvetica.  Not  all  tagged  text  systems  are  able  to  specify  colored 
text. 

3.12.1.2.4  Portability  caveats.  At  present,  portability  using  ODA/ODIF  is  limited,  because  it  is 
not  in  widespread  use  or  widely  available,  although  SGML  is  widely  available. 

3.12.1.2.5  Related  standards.  The  following  standards  are  related  to  document  exchange: 
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a.  ISO  8824:1987  and  ISO  8825:1987  -  ASN.l/BER 

b.  SGML  for  documents  that  are  not  predefined 

c.  TeX  by  Donald  Knuth  of  MIT  and  LiTeX  macros  are  widely  used  for  typesetting, 
especially  for  documents  that  include  mathematics 

3.12.1.2.6  Recommendations.  In  keeping  with  the  ongoing  shift  from  literal  page  appearance  to 
electronic  transfer  of  document  content  (as  exemplified  by  the  electronic  commerce  and  CALS 
programs)  we  recommend  the  use  of  SGML  for  document  interchange.  Alternative  standards  - 
Adherence  to  CALS  specifications  and  standards  should  be  maintained  to  the  maximum  extent 
possible,  as  use  of  CALS  provides  maximum  interoperability.  In  the  event  that  a  CALS  standard 
cannot  convey  the  technical  information  of  a  particular  application,  only  then  is  the  use  of  a  non- 
CALS  standard  justified.  On  March  25-26, 1993,  the  Defense  Information  Systems  Agency 
(DISA)  convened  a  Document  Interchange  Symposium.  The  symposium  featured  a  panel  of 
ODA  and  SGML  experts  to  deliberate  on  SGML/ODA  issues.  The  panel  reached  the  following 
conclusions: 

SGML  has  been  adopted  by  a  wide  range  of  government  and  private  industry 
initiatives  for  document  interchange. 

b.  Few  commercially  viable  ODA  products  are  found  in  the  U.S.  marketplace. 

c.  Distinctions  between  office  and  publishing  documents  are  diminishing  (making  the 
need  for  unique  office  document  architectures  less  acute). 

d.  SGML  has  been  adopted  by  the  publishing  community. 

In  addition  to  the  panel's  conclusions,  it  should  be  noted  that  NIST  has  decided  not  to  develop  a 
FIPS  for  ODA.  The  DOD  SGML  standard  (MIL-PRF-28001)  is  based  on  ISO  8879.  MIL- 
HDBK-28001  for  SGML  is  being  developed. 

For  documents  intended  for  distribution  on  the  Internet,  particularly  the  World  Wide  Web,  HTML 
should  be  used.  HTML  is  a  document  type  definition  (DTD)  of  SGML  for  Internet  documents. 

Adobe  PDF  is  being  used  frequently  in  DOD  for  formatting  documents  where  revisions  are  not 
required.  However,  PDF  suffers  by  the  fact  that  it  has  not  yet  been  endorsed  by  an  open 
consensus  standards  body.  Efforts  need  to  be  taken  to  move  PDF  from  the  de  facto,  proprietary, 
realm  to  be  an  open  standard. 
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3.12.1.3  Font  information  interchange.  (This  BSA  appears  in  part  3,  Data  Interchange,  and 
part  12,  Multimedia.)  Font  information  interchange  standards  specify  the  encoding  of  font 
resource  information  for  use  in  document  processing  environments.  Font  interchange  deals  with 
the  exchange  of  character  fonts,  such  as  Times  Roman  or  Helvetica,  and  related  information  as 
opposed  to  simple  exchange  of  character  encodings,  which  do  not  include  font  information. 

3.12.1.3.1  Standards.  Table  3.12-3  presents  standards  for  font  information  interchange. 


TABLE  3.12-3  Font  Information  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/TEC 

Foot  Information  Interchange,  Part  1:  Architecture 
(Corrigendum  1-1992,  Corrigendum  2-1994) 

9541-1:1991 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  2:  Interchange  Format 
(Corrigendum  1-1993) 

9541-2:1991 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Foot  Information  Interchange,  Part  3:  Glyph  Shape 
RepreaeaUdon 

9541-3:1994 

Adopted 

(Approved) 

IPC 

ISO/IEC 

Font  Information  Interchange  -  Procedure  for  Regiitretion 
of  Glyph  and  Glyph  Collection  Identifier! 

10036:1993 

Informational 

(Approved) 

CPC 

NIST 

IjjjjHjgragjgjjjgH 

FIPS  PUB  90:1983 

Informational 

(Approved) 

CPN-C 

Adobe 

PoatScript  Type  I  -  Outline! 

PS  Tech.  Manual! 

Informational 

(Approved) 

CPN-C 

Microsoft 

TrueType  -  Outline* 

TTTech.  Manual* 

Informational 

(Approved) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  4:  Character  Collection* 

9541-4 

Informational 

(Draft) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  5:  Font  Attribute*  and 
Chancier  Model 

9541-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  6:  Font  and  Character 
Attribute  Subaet*  and  Application 

9541-6 

Informational 

(Draft) 

IPC 

ISO/IEC 

Font  Information  Interchange,  Part  7:  Font  Interchange 
Format 

9541-7 

Ltformaliona! 

(Draft) 

3.12.1.3.2  Alternative  specifications.  Alternative  specifications  include  TrueType  and 
PostScript. 

3.12.1.3.3  Standards  deficiencies.  There  is  and  will  be  very  little  standardization  of  font  names, 
because  of  copyright  concerns.  None  of  the  existing  font  interchange  standards  accurately  enable 
font  substitution.  However,  many  systems  are  attempting  font  substitution,  that  is,  replacing  a 
specified  font  with  one  that  is  similar,  such  as  substituting  TrueType  Arial  for  PostScript 
Helvetica. 


No  standard  exists  for  three-dimensional  font  families,  although  such  text  is  becoming  popular  in 
display  text  applications,  such  as  advertising  and  presentations. 
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3.12.13.4  Portability  caveats.  Target  presentation  systems  and  viewers  may  not  have  the 
required  fonts  to  construct  the  called-for  text  in  a  presentation  system.  Font  substitution  may 
result  in  an  unexpected  text  presentation.  Outline  font  geometry  also  can  be  represented  as  two- 
dimensional  graphics  geometry,  which  eliminates  the  need  to  support  a  specific  font  on  a  target 
platform. 

3.12.133  Related  standards.  Standards  related  to  font  information  interchange  standards  are: 

a.  ISO  8632:  Computer  Graphics  Metafile  (CGM) 

b.  X  Logical  Font  Description  (see  part  3) 

c.  PostScript  Level  2  (starting  to  be  used  for  colored  text) 

3.12.13.6  Recommendations.  If  CGM  is  being  used,  then  ISO  8632-1  DAM  3  also  is  needed  for 
font  information  exchange  along  with  ISO  9541.  The  ISO  9541  specifies  the  architecture  and 
format  for  various  shape  descriptions  to  be  used  in  document  processing  environments  that 
recognize  Abstract  Syntax  Notation  (ASN).l  or  SGML  parsing  algorithms.  ISO  9541  uses  Adobe 
System's  PostScript  Type-I  font  technology  and  file  formats.  The  ISO  9541  is  recommended  for 
font  information  exchange. 

For  some  applications,  such  as  view-only  kiosks  and  presentations,  convert  text  to  a  graphics 
format  to  avoid  unknown  font  resource  issues.  Use  fonts  that  are  in  common  usage  for  cross- 
platform  work. 
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3.12.1.4  Printer  date  interchange.  Printer  data  interchange  is  performed  by  using  page 
description  languages  to  describe  a  page  to  be  printed  so  the  printer  processor  can  convert  the 
representation  directly  into  a  page  image  for  any  printer. 

3.12.1.4.1  Standards.  Table  3.12-4  presents  standards  for  display  text  interchange. 


TABLE  3.12-4  Printer  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

JSO/IEC 

Standanl  ptge  Description  Language  (SPDL) 

10180:1992 

Informational 

(Approved) 

IPC 

ISO/EC 

Standard  for  the  Exchange  of  Product  Model  Data  (STEP), 
Part  46:  Integrated  Generic  Resource* ;  Visual  Presentation 

10303-46:1994 

Informational 

(Approved) 

CPN-C 

Adobe 

Encapsulated  PostScript  Format  (EPSF) 

EPSF  Level  1 

Informational 

(Approved) 

CPN-C 

Adobe 

Portable  Document  Former  (PDF) 

PDF 

Informational 

(Approved) 

IPC 

ISO/TEC 

Infocmation  Technology  -  Text  and  office  lyttemi  • 
Document  Printing  Application  (DPA)  -  Part  2:  Protocol 
specification 

10175-2:1996 

Informational 

(Approved) 

IPC 

1SOAEC 

Information  Technology  •  Text  and  office  sytiems  - 
Document  Printing  Application  (DPA).  Part  1:  Abstract 
service  definition  and  procedures 

10175-1:1996 

Informational 

(Approved) 

3.12.1.4.2  Alternative  specifications.  The  following  de  facto  specifications  are  available: 

a.  Adobe:  PostScript  and  Display  PostScript 

b.  Hewlett-Packard:  Hewlett-Packard  Page  Description  Language  (HPDL) 

c.  Xerox:  Interpress 

3.12.1.4.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.12.1.4.4  Portability  caveats.  ISO  10180,  Standard  Page  Description  Language  (SPDL), 
combines  the  best  of  Adobe  PostScript  and  Xerox  Interpress,  along  with  enhancements  and 
extensions  developed  by  ISO.  However,  it  is  not  a  superset  of  the  PostScript  and  Interpress  page 
description  languages.  The  inclusion  of  parts  of  each  vendor's  page  description,  as  well  as  the  ISO 
extensions,  render  it  incompatible  with  either  PostScript  or  Interpress. 

Although  it  is  a  proprietary  standard,  EPSF  is  widely  supported  for  importation  of  display  text. 
However,  care  should  be  taken  to  ensure  that  tools  used  to  deliver  titles  support  importation  of 
EPSF.  Many  raster  image  formats  are  candidates  for  this  purpose. 

3.12.1.4.5  Related  standards.  No  standards  are  related  to  page  description  exchange  standards. 

3.12.1.4.6  Recommendations.  If  specifying  SPDL  in  a  procurement,  the  specification  of  a 
converter  box  that  converts  formats  such  as  PostScript,  Interpress,  or  HPDL  to  SPDL  is 
recommended.  SPDL  is  a  standard  with  no  commercial  following.  The  proprietary  specifications, 
such  as  PostScript  and  PDF,  are  dominant.  If  used,  EPSF  or  PDF  should  be  considered  as  an 
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interim  solution  only  until  a  public  standard  is  available.  Adobe  PDF  is  being  used  frequently  in 
DOD  for  formatting  documents  where  revisions  are  not  requited.  However,  PDF  suffers  by  the 
fact  that  it  has  not  been  endorsed  by  an  open  consensus  standards  body. 
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3.12.1.5  Two-dimensional  graphics  interchange.  Two-dimensional  graphics  interchange 
standards  deal  with  computer  graphics  that  are  represented  by  geometric  encoding  as  opposed  to 
images  that  are  represented  as  bitmaps. 


3.12.1 .5.1  Standards.  Table  3.12-5  presents  multimedia  standards  for  two-dimensional  graphics 
interchange. 


TABLE  3.12-5  Two-dimensional  graphics  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/D2C 

MeUfUe  for  SloragtyTrunsfer  of  Pictorial  Description 
Information  (COM)  (as  profiled  by  PIPS  PUB  128-1  and 
MIL-STD-230!) 

8632- U.3,4i  1992 
(w/Amd  1A2) 

Mandated 

(Approved) 

NPC/IPC 

ANSI/ISO/IEC 

Programmers'  Hierarchical  Interactive  Graphics  System 
(PHIGS  tod  PHIGS  PLUS)  (as  profiled  by  FIPS  PUB  153- 
1) 

9592-1,2,3,4:1989 
with  AMD1:1992 

Mandated 

(Approved) 

IPC 

ISO/tHC 

Graphical  Kernel  Syrian  (GKS)  functional  description  API 
(ANSI  X3.124H985  as  profiled  by  FIPS  PUB  120-1:1991) 

7942:1985 

Mandated 

(Approved) 

CPC 

MITX 

Condo  itj  urn 

Data  Stream  Encoding  (X  Protocol) 

XUK5 

Informational 

(Approved) 

CPN-C 

Ah* 

PICT  and  P1CT32 

Apple  SDK 

Informational 

(Approved) 

cmc 

Microsoft 

Windows  32-bit  Graphics  Device  Interface  (WIN32-ODI) 

WIN32  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Microsoft 

Windows  Metafile  and  Graphics  Device  Interface 
(WMP/GDI)  (16-bit) 

WMF  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Autodesk 

Document  Exchange  Format  (DXF) 

DXF  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Microsoft 

Visual  Basic 

Tech.  Manuals 

Informational 

(Approved) 

CPN-C 

IBM 

Graphics  Programming  Exchange  (GPB),  PM  2,1 

OPE  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

IBM 

GPI  (API) 

PM  2.1 

Informational 

(Approved) 

CPN-C 

Microsoft 

W1N16-GDI  (API) 

Windows  SDK 

Informational 

(Approved) 

CPN-C 

An* 

Quickdraw32  (API) 

Quickdraw 

Informational 

(Approved) 

3.12.1.5.2  Alternative  specifications.  None. 

3.12.1.5.3  Standards  deficiencies.  Some  features  are  added  to  PHIGS  implementations  to 
compensate  for  perceived  deficiencies  in  the  standard. 

3.12.1.5.4  Portability  caveats.  In  2  1/2-dimensional  work  where  front-to-back  ordering  of 
graphical  objects  is  important,  the  order  may  be  lost  when  converting  from  an  application 
program  to  an  interchange  format. 
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Most  implementations  of  PHIQS  provide  extra  features  that  are  not  part  of  the  PHIGS  standard 
and  often  are  unnecessary  for  typical  graphics  development  These  features  must  be  avoided  if 
possible,  since  unique  features  limit  portability. 

3.12.15  J  Related  standards.  The  following  standards  are  related  to  two-dimensional  graphics 
interchange: 

a.  ISO/IEC  9593-1:  PHIGS  Language  Bindings  -  Part  1:  FORTRAN  (Corrigendum 
1:1993, 2:1994). 

b.  ISO/IEC  9593-2:  PHIGS  Language  Bindings  -  Part  3:  Ada  (Amd  1  1994,  Corr.  1 

1993) 

c.  ISO/IEC  9593-4:  PHIGS  Language  Bindings  -  Part  4:  C  (Amd  1  1994  Corr.  1 

1994) 

3.12.1.5.6  Recommendations.  ISO  8632  CGM  (MIL-PRF-28003A,  MIL-STD-2301,  FIPS  128- 
1)  and  PHIGS/PHIGS+  (FIPS  153,  ISO  9592)  are  recommended.  PHIGS  standards  should  be 
used  without  nonstandard  features.  PHIGS  supports  both  two-  and  three-  dimensional  graphics. 
GKS  functionality  is  totally  subsumed  and  extended  by  PHIGS. 
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3.12.1.6  Three-dimensional  graphics  interchange.  Three-dimensional  graphics  are  typically 
used  for  CAD/CAM  and  CAE  applications.  The  interchange  is  used  to  directly  convey  from 
computer  to  computer  the  physical  design  and  shape  characteristics  of  an  object  or  model. 
However,  three-dimensional  graphics  are  becoming  more  popular  in  many  multimedia 
applications. 

3.I2.1.6.I  Standards.  Table  3.12-6  presents  multimedia  standards  for  three-dimensional  graphics 
interchange  formats. 


TABLE  3.12-6  Three-dimensional  graphics  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPC/IPC 

ANSI/1SO/IEC 

jgjgffl 

Mandated 

(Approved) 

GPC 

NIST 

Initial  Graphic*  Exchange  Specification  (IGES)  (adopU 
ASME/ANSl  Y14.26M-1989)  (IGES  ver.  4) 

FIPS  PUB 
177:1992 

Infonnational 

(Approved) 

GPC 

DOD 

Digital  Repreaentation  for  Communication  of  Product 
Data:  IGES  Application  SubaeU  and  IGES  Application 
Protocol! 

MIL-PRF-28000 

Informational 

(Approved) 

CPC 

MIT  X 
Cotuortium 

X  Coojoitium’i  PH IGS -baaed  3-D  Extension  to  the  X 
Window  Sytiem  (PEX) 

XI  IRS 

Infonnational 

(Approved) 

CPC 

MITX 

Consortium 

X  Consortium'*  PHIGS-baaed  3-D  Extension  to  X  Window 
Sy  item  (PEX) 

X11R6 

Infonnational 

(Approved) 

NPC 

ANSI/SAB 

Initial  Graphic*  Exchange  Specification 

Infonnational 

(Approved) 

CPN-C 

SOI 

VRML  vl.O 
5/26/1995 

Infonnational 

(Approved) 

CPN-C 

Pi  Mr 

Renderman  -  RIB  (Language,  API) 

Tech.  Manuala 

Infonnational 

(Approved) 

CPN-C 

SGI 

Graphics  Language  (GL)  (Language,  API) 

Tech.  Manual* 

Infonnational  [ 
(Approved) 

3.12.1.6.2  Alternative  specifications.  None. 

3.12.1.6.3  Standards  deficiencies.  IGES  does  not  handle  all  interfaces  between  the  data 
exchange  specifications  and  external  components,  such  as  the  interface  between  the  product  data 
specification  and  numerically  controlled  machining  tools.  IGES  does  not  cover  the  complete  life 
cycle  of  manufactured  products,  It  addresses  only  the  specification  of  products  and  not  the 
manufacturing  process  relationships.  The  DOD/CALS  IGES  standard  is  preferred  for  engineering 
drawings,  electronics,  and  numerical  control,  The  standard  is  optional  for  technical  manual 
illustrations. 

Some  features  are  added  to  PH1GS  implementations  to  compensate  for  perceived  deficiencies  in 
the  standard. 
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3.12.1.6.4  Portability  caveats.  Most  implementations  of  PHIGS  provide  extra  features  that  are 
not  part  of  the  PHIGS  standard  and  often  are  unnecessary  for  typical  graphics  development 
These  features  must  be  avoided  if  possible,  since  unique  features  limit  portability. 

3.12.1.6.5  Related  standards.  The  following  standards  are  related  to  three-dimensional  graphics 
interchange: 

a.  ISO  8805:  Graphical  Kernel  System  for  Three  Dimensions  (GKS-3D)  functional 
description 

b.  RenderMan 

c.  Silicon  Graphics:  Graphics  Language 

d.  Dore:  Dore  Reference  Manual 

e.  ISO/IEC  9593- 1 :  PHIGS  Language  Bindings  -  Part  1 :  FORTRAN  (Corrigendum 
1:  1993,2:1994) 

f.  ISO/IEC  9593-3:  PHIGS  Language  Bindings  -  Part  2:  Ada  (Amd  1 : 1 994,  Corn 
1:1993) 

g.  ISO/IEC  9593-4:  PHIGS  Language  Bindings  -  Part  4:  C  (Amd  1 :  1994,  Com  1 : 
1994) 

3.12.1.6.6  Recommendations.  PHIGS  (FIPS  153,  ISO  9592)  should  be  used  as  appropriate. 
PHIGS  includes  language  bindings  for  C,  FORTRAN,  and  Ada.  PHIGS  supports  both  two-  and 
three-  dimensional  graphics.  GKS-3D  functionality  is  totally  subsumed  and  extended  by  PHIGS. 
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3.12.1.7  Animated  graphics  interchange.  Animated  graphics  include  two-  and  three- 
dimensional  graphics  that  are  presented  as  motion  sequences.  The  motion  is  generated  internally 
by  a  computer  system.  This  differs  from  motion  images,  which  translate  motion  captured  with  a 
camera  for  computer  display. 

3.12.1.7.1  Standards.  Table  3.12-7  presents  multimedia  standards  for  two-  and  three- 
dimensional  animated  graphics  interchange. 


TABLE  3.12-7  Animated  graphics  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPN-C 

Autodesk 

Flick  Filer  (FLI  4  FLC) 

FLI,  FLC  Tech. 
Manual  i 

Info  rotational 
(Approved) 

CPN-C 

Micro*)  ft 

Audio  Video  Interactive  (AVI) 

AVI  Tech.  Manuals 

Informational 

(Approved) 

CPN-C 

Apple 

QuickTime 

QuickTime  2.S 

Infoimational 

(Approved) 

3.12.1.72  Alternative  specifications.  None. 

3.12.1.72  Standards  deficiencies.  No  IPC,  NPC,  or  GPC  standards  exist  for  two-dimensional 
animated  graphics.  No  standards  exist  for  three-dimensional  graphics. 

3.12.1.7.4  Portability  caveats.  Exchanging  animation  across  applications  and  platforms  is  not 
well  supported. 

3.12.1.7.5  Related  standards.  None. 

3.12.1.7.6  Recommendations.  If  two-dimensional  animation  is  required,  the  CPN-C  standards 
above  should  be  considered  as  interim  solutions  only.  Autodesk  Flick  Files  (FL1  &  FLC)  are  the 
only  interchange  files  aimed  solely  at  two-dimensional  animated  graphics.  The  two  formats  differ 
in  resolution.  FLI  files  support  320  x  200  while  FLC  files  are  resolution-dependent,  although  they 
commonly  resolve  to  640  x  400. 
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3.12.1.8  Still  image  interchange.  Still  images  are  images,  such  as  photographs,  that  are 
described  by  bitmaps,  as  opposed  to  vector  graphics  which  are  described  with  geometric  notation. 

3.12.1.8.1  Standards.  Table  3.12-8  presents  multimedia  standards  for  still  image  interchange. 


TABLE  3.12-8  Still  image  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

JPC 

ISO/IEC 

igBaSi&SaB 

10918-1:1994 

Mandated 

(Approved) 

GPC 

DOD 

National  Imagery  Transmission  Format  version  2.0 

MIL-STD.2500A 

Mandated 

(Approved) 

GPC 

DOD 

Bi-Levd  Image  Compression  for  the  National  Imagery 
Transmission  Format  Standards  (NITFS) 

MIL-STD- 188-196 
of  6/18/1993 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Digital  Compression  sod  Coding  of  Continuous-Tooe  Still 
Images  -  Part  2;  Compliance  Testing 

10918-2:1993 

Informational 

(Approved) 

GPC 

NIST 

Standard  for  the  Interchange  of  Large  Format  Tiled 
Documents 

NISTIR  88-4017 

Infoimational 

(Approved) 

GPC 

DOD 

Requirements  for  Raster  Graphics  Representation  in  Binary 
Format  (Group  4  Raster  Scanned  Images) 

MIL-PRF-28002 

Informational 

(Approved) 

IPC 

ISO/IEC 

Progressive  Bi-Level  Image  Compression  (JBIG) 
Compression  Algorithm  for  Black-and- White  Images 

11544 

(Corrigendum 

1):  1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  Functional 
Specification,  Part  3:  Image  Interchange  Facility  (IIP) 

12087-3:1995 

Informational 

(Approved) 

IPC 

ANSl/NPESA 

IT8.8 

Informational 

(Approved) 

IPC 

ISO/IEC 

12087-1:1995 

Informational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  Functional 
Specification:  Part  2:  Programmers  Imaging  Kernel  System 
API 

12087-2:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Image  Processing  and  Interchange  (IPI)  API  Language 
Bindings  Part  4:  C 

12088-4:1995 

Informational 

(Approved) 

CPC 

Various 

Photo  CD 

Photo  CD  Tech. 
Manuals 

Infoimational 

(Approved) 

CPN-C 

Adobe 

PostScript  Level  2 

PS  Tech.  Manuals 

Informational 

(Approved) 

CPN-C 

Adobe 

Portable  Document  Format  (PDF) 

PDF 

Informational 

(Approved) 

CPN-C 

CompuServe 

Graphics  Interchange  Format  (GIF) 

Gil  7a  and  89a 

Informational 

(Approved) 

CPN-C 

ACR/NEMA 

Medical  Informatics  Standard 

Sic.  Pub.  No.  300 

Informational 

(Approved) 

CPN-C 

Aldus 

Tagged  Image  File  Formal  (TIFF) 

TIFF  v.  6.0, 1992 

Infoimational 

(Approved) 

CPN-C 

Z-Soft 

PC  Paintbrush  Formal  (PCX) 

PCX  Tech. 
Manuals 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPN-C 

.Microtoft 

WIN  16  -  DIB/WMF 

Win  3.1  SDK 

Informational 

(Approved) 

CPN-C 

Trueviiioo 

Tug*  32 

Informational 

(Approved) 

CPN-C 

Microsoft 

WIN  16  -  BMP/WMF 

Win  3.1  SDK 

Informational 

(Approved) 

IPC 

ISO/IEC 

Digital  Compresaioo  and  Coding  of  Continuous-Tone  Still 
Images  -  Pan  3:  Bjrtanaiona 

10918-3:1995 

Informational 

(Draft) 

IPC 

ISO/IEC 

Image  Proccanng  and  Interchange  (IPI)  Functional 
Specification,  Part  3:  Image  Interdiange  Facility  (UF) 
Ameocknent  1 :  Type  Definition,  Scoping,  and  Logical 
Views  for  Image  Interchange  Facility 

12087-3  DAM 
1:1994 

IPC 

1SO/IEC 

Image  Processing  and  Interchange  (IPI)  API  Language 
Bindinti,Part4:C 

CD 12087*4: 

Informational 

(Draft) 

3.12.1.8.2  Alternative  specifications.  Photo  CD  has  five  variations  of  CD  formats  announced, 
including  one  for  the  medical  industry.  Many  proprietary  image  formats  exist 

3.12.1. 8J  Standards  deficiencies.  Not  all  standards  can  handle  the  interchange  of  calibrated 
color  information.  Notably,  RGB  formats  are  usually  unreferenced  as  to  the  colorimetric 
definition  of  pure  red. 

Exchanging  JPEG  images  across  different  implementations  can  lead  to  slightly  inconsistent  images 
when  compared  one-for-one  with  the  original.  Round-off  errors  in  internal  arithmetic  are  not  all 
the  same. 

No  standard  algorithm  exists  for  the  reduction  or  color  spaces  from  24  to  16  to  8  to  4  bits. 
Different  platforms  handle  color  degradation  differently. 

3.12.1.8.4  Portability  caveats.  Even  if  calibrated  color  is  included  with  the  image,  not  all 
applications  or  platforms  can  handle  the  specifications.  Some  low-end  pre-press  systems  are 
becoming  color-literate.  Photo  CD  does  handle  calibrated  color  information. 

Because  approval  of  ISO  12087  is  so  recent,  implementations  may  be  limited. 

Adobe  PDF  is  being  used  frequently  in  DOD  for  formatting  documents  where  revisions  by  the 
end-user  are  not  required. 

3.12.1.8.5  Related  standards.  The  following  standards  and  types  of  standards  are  related  to  still 
image  interchange: 

a.  CIE  Colorimetric  standards 

b.  Various  facsimile  standards 
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c.  Microsoft  Resource  Interchange  File  Format  (RIFF) 

d.  Apple  Bento  container  format 

e.  ISO  8632  (COM) 

f.  NIST  FIPS  1 53- 1 ,  X  Windows,  for  Bitmap  Distribution  Format 

g.  X/Open  C170,  X  Window  System  File  Formats  and  Application  Conventions 
(BDF) 

h.  X  Consortium,  Bitmap  Distribution  Format  (BDF),  v.  2. 1 

CGM  includes  support  for  bit-mapped  images,  although  it  is  seldom  used  for  still  image 
interchange. 

J.12.1.8.6  Recommendations.  JPEG  (MIL-STD-188-198A,  ISO  10918)  should  be  used  for  most 
applications  involving  compressed  still  image* ,  Although  JPEG  includes  lossless  compression, 
virtually  all  JPEG  images  are  created  usin g  lossy  compression.  This  means  that  information  is  lost 
when  the  image  is  compressed.  Source  images,  prior  to  compression,  should  be  maintained. 

JPEG  supports  multiple  levels  of  lossy  compression.  The  degree  of  compression  influences  the 
amount  of  information  lost  and  image  quality  upon  decompression.  Compression  levels  should  be 
tailored  to  image  quality  requirements.  While  lossy  JPEG  images  typically  display  at  high  quality 
on  computer  monitors,  the  quality  may  be  somewhat  diminished  on  hardcopy  output  devices  such 
as  high-resolution  color  printers. 

MIL-PRF-28002B  should  be  used  in  a  CALS  environment,  and  when  needed,  supplemented  by 
NIST  IR  88-4017  (tiling).  Tiling  and  compression  are  desirable  for  vt.'.ry  large  still  images.  This 
version  (MIL-PRF-28002B)  supports  raster  data. 

If  the  compression  scheme  defined  in  MIL-STD-2500A  is  specified  in  a  procurement,  a  migration 
strategy  to  JPEG  should  be  required.  M1L-STD-2500A  supports  ITU-T  Group  HI  compression 
while  CALS  supports  Group  IV  only.  Use  the  NI'l'FS  compression  standards  or  CALS 
compression  standard,  as  applicable. 

ISO  1 1544  (JBIG)  should  be  considered  when  lossless  image  compression  of  black  and  white 
images  is  required. 

ISO/IEC  12087  is  the  only  IPC  standard  for  still-image  APIs.  This  standard  should  be  used  if 
available  implementations  can  meet  mission  requirements. 

Select  aspect  ratios  and  resolutions  equal  to  or  greater  than  those  available  on  target  platforms,  to 
protect  against  new  display  sizes  and  resolutions.  Source  images  should  be  maintained  for 
archival  and  reuse  purposes. 


April  7.  1997 


3.12-19 


Version  3. 1 


Information  Technology 


MnhimrHia  SwvicM 


3.12.1.9  Motion  video  inter  change.  Motion  video  interchange  includes  standards  for  motion 
video  and  associated  audio.  Animation  (3. 12. 1.6)  and  live  video-audio  exchange  through  video 
teleconferencing  (VTC;  (3.12.5)  are  not  included. 

3.12.1.9.1  Standards.  Table  3.12-9  presents  multimedia  standards  for  motion  video  interchange. 


TABLE  3.12-9  Motion  video  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Coding  of  Moving  Picture*  and  Ai  tod  Med  Audio  for 
Digital  Stonge  Media  up  to  about  1.5  Mbit/anc  (MPEG  IX 
Part  1:  Syrtwni,  Part  2:  Video,  Part  3:  Audio  (with 
Technical  Corrigendum  1:1996) 

1 1 172- 1,2,3: 1993 

Mandated 

(Approved) 

IPC 

ISOflEC 

Generic  Coding  of  Moving  Pictures  aud  Aiaociaied  Audio 
Information  (MPEG2),  Part  1:  Systems 

13818-1:1996 

Mandated 

(Approved) 

B-C 

ISO/IEC 

Generic  Coding  of  Moving  Picture*  and  Associated  Audio 
information  (MPEG2),  Part  2:  Video 

13818-2:1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Picture*  and  Asaodaiad  Audio 
Information  (MPEG  2),  Part  3:  Audio 

13818-3:1995  with 
Arad  1 

Mandated 

(Approved) 

IPC 

ISO/IEC 

13818-9:1996 

Informational 

(Approved) 

IPC 

ISO/IEC 

Coding  of  Moving  Pictuim  and  Associated  Audio  for 
Digital  Stonge  Media  up  to  about  1.5  Mbit/sec  (MPEG  I), 
Part  4:  Conformance  Testing 

11172-4: 1995 

Informational 

(Approved) 

GPC 

DOD 

Military  Training  Programs  (Video  exchange) 

MIL-STD-1379D 
of  12/5/1990 

Informational 

(Approved) 

CPC 

IMA 

Recommended  Practices  for  Multimedia  Portability,  v.  1 . 1 
(analog  video) 

IMA-RP,  1990 

InfotmationaJ 

(Approved) 

IPC 

rru-R 

Characteristics  of  Television  Systems  -  Characteristics  of 
Systems  for  Monochrome  and  Colour  Television 

Report  624-4:  1990 

Informational 

(Approved) 

IPC 

IEC 

Phase  Alternating  Line  (PAL)  for  television  (analog  video) 

1146 

Informational 

(Approved) 

IPC 

rru-R 

Encoding  Parameters  of  Digital  Television  for  Studios 

601-2 

Informational 

(Approved) 

CPC 

IMA 

Recommended  Practices  for  MultimedU  Portability,  v.  1.2 
(analog  video,  indudes  MIDI) 

IMA-RP.  1993 

Informational 

(Approved) 

CPN-C 

Apple 

QuickTime 

QuickTime  2.5 

Informational 

(Approved) 

(PNC 

Truevision 

Targe- 16,  Targa-24 

Targe- 16,  24 

Informational  | 
(Approved)  | 

CPN-C 

Microsoft 

Video  1,  RLE  A  Indeo.  RIFF-  AVI  Files 

Tech  Manuals 

Informational  J 
(Approved)  | 

CPN-C 

Intel 

Digital  Video  Interactive  (DVI) 

DVI  Tech.  Manuals 

Information*!  1 
(Approved) 

CPN-C 

Pioneer 

Video  Disc  (analog  video) 

Tech.  Manuals 

Informational 

(Approved) 

CPN-C 

Microsoft 

Vi(fco  for  Window.  t.OAPI 

MM  SDK  Tech. 
Manuals 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPN-C 

Truevision 

Taiga  Development  1 .0  (ttfibcabon) 

Taiga  Dev.  1.0 
Tech.  Manual* 

Informational 

(Approved) 

IPC 

ISO/IEC 

11172-5 

Informational 

(Draft) 

n*c 

ISO/IEC 

Geoeric  Modmg  erf  Moving  Picture*  and  Associated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Testing 

13818-4 

Emerging 

(Draft) 

IPC 

ISO/IEC 

Generic  Coding  oi  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  5:  Software  Simulation 

13818-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

13818-6 

Informational 

(Daft) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  7:  Audio  Extensions 

13818-7:1993 

Informational 

(Draft) 

3.12.1.9.2  Alternative  specifications.  None. 

3. 12.1. 9 J  Standards  deficiencies.  Animation,  synchronization,  and  degradation  control  are  not 
well  supported  in  any  of  the  current  digital-video  environment 

3.12.1.9.4  Portability  caveats.  The  ability  of  mtny  platforms  to  display  motion  video  is  limited 
by  platform  performance.  Fi'll-screen,  full-motion  video  usually  requires  special  decompression 
hardware.  Therefore,  motion  video,  especially  video  that  uses  software  decompression,  should 
use  the  minimum  image  size  and  frame  rate  required. 

NTSr  is  the  U.S.  standard  for  analog  television  resolution.  PAL  is  a  common  European  standard. 
SEw»M  is  used  in  France,  Eastern  Europe,  parts  of  Africa,  and  the  Middle  East. 

Although  MPEG  1  is  rapidly  emerging  as  the  standard  for  computer-based  motion  video, 
especially  from  CD-ROM,  decoding  MPEG  1  at  reasonable  image  sizes  and  frame  rates  requires 
special  hardware  assistance.  Therefore,  MPEG  1  should  not  be  considered  portable  to  legacy 
systems  that  do  not  include  MPEG  1  decompression  hardware.  It  is  expected  that  many  future 
computer  systems  will  include  MPEG  1  hardware. 

MPEG  1  provides  for  a  wide  range  of  video  resolutions  and  data  rates  but  is  optimized  for  single 
and  double-speed  CD-ROM  data  rates  (1.2  and  2.4  Mbits/s).  With  30  frames  per  second  video  at 
a  display  resolution  of  352  x  240  pixels,  the  quality  of  compressed  and  decompressed  video  at  this 
data  rate  is  often  described  as  similar  to  VHS  recording.  MPEG  1  is  frequently  used  in 
applications  with  limited  bandwidth,  such  as  CD-ROM  playback  or  Integrated  Services  Digital 
Network  (ISDN)  videoconferencing. 

MPEG  2  is  designed  for  the  encoding,  compression,  and  storage  of  studio-quality  motion  video 
and  multiple  CD-quality  audio  channels  at  bit  rates  of  4  to  6  Mbits/s.  MPEG  2  has  also  been 
extended  to  cover  HDTV. 
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Programming  models  are  generally  in  a  state  of  flux,  especially  at  the  operating  system  level  As  a 
result,  any  code  development  will  probably  not  port,  especially  if  performance  advantages  are 
taken  in  the  imaging,  audio,  and  video  areas.  QuickTime  and  Video  for  Windows  are  currently 
available  for  both  Apple  System  7  and  Microsoft  Windows. 

3.12.-.9.5  Related  standards.  The  following  standards  are  related  to  motion  video: 

a.  ISO  10918  (JPEG) 

JPEG  is  used  for  motion  video  in  non-linear  editing  systems  with  proprietary  decompression 
hardware.  It  is  preferred  for  such  systems  because  each  frame  is  compressed  in  isolation,  allowing 
direct  access  to  and  editing  of  individual  frames.  However,  ISO  10918  does  not  include  motion 
specifications. 

3.12.1.9.6  Recommendations.  MPEG  1  (ISO  1 1 172)  is  the  emerging  motion  video  standard  for 
computer  systems  and  should  be  used  for  distribution  to  systems  that  include  MPEG  1 
decompression  hardware.  For  distribution  to  legacy  systems  that  do  not  include  MPEG  1 
hardware,  software  solutions,  such  as  Microsoft  Audio  Video  Interactive  (AVI),  should  be 
considered  as  interim  solutions. 

MIL-STD-1279D  should  be  used  for  interactive  training  delivered  on  level-3  laserdisc  systems 
using  the  MS  DOS  operating  system. 

MPEG  2  (ISO  13818)  is  optimal  for  a  variety  of  data  rates  ranging  from  3  to  10  Mbits/s  and 
higher.  It  is  expected  to  be  used  in  the  cable  industry’s  planned  500-channel  systems  and  for  the 
emerging  Video  CD  technology. 

Maintain  original  video  for  archival  and  re-use  purposes. 
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3.12.1.10  Digital  audio  interchange.  Digital  audio,  also  called  sampled  audio,  consists  of 
information  that  is  recorded  as  digital  samples  that  are  played  back  directly  by  digital-to-analog 
conversion. 

3.12.1.10.1  Standards.  Table  3.12-10  presents  multimedia  standards  for  digital  audio 
interchange. 


TABLE  3.12-10  Digital  audio  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Coding  of  Moving  Picture*  nod  Associated  Audio  for 
Digital  Storage  Media  Vo  to  about  1.5  Mbit/sec  (MPEG  1), 
Part  i:  System,  Part  2i  Video,  Part  3;  Audio  (with 
Tedmkal  Corrigendum  1:1996) 

11172-1,2,3:1993 

Mandated 

(Approved) 

tPC 

1SO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  3:  Audio 

13818-3:1995  with 
Amd  1 

Mandated 

(Approved) 

IPC 

ITU-T 

Pulse  Code  Modulation  (PCM)  of  voice  frequencies 
(narrowband) 

G.711:1989 

Informational 

(Approved) 

IPC 

ITU-T 

7  KHz  Audio  Encoding  within  64  kbit/s  (broadband) 

G.722(1939) 

Informational 

(Approved) 

IPC 

Extensions  of  G.721  to  24  and  40  kbit/s  for  Digital  Circuit 
Multiplication  Equipment  Application 

G.723  (1989) 

Informational 

(Approved) 

IPC 

ITU-T 

40, 32, 24,  and  16  kbit/s  Adaptive  Digital  iNilse  Code 

Modulation  (ADPCM) 

0.726(1990) 

Informational 

(Approved) 

IPC 

ITU-T 

Coding  of  Speech  at  16  kbiu/s  using  Low-Delay  Code 
Excited  Linear  Prediction  (LD-CELP). 

0.728:1992 

Informational 

(Approved) 

CPC 

IMA 

1  Recommended  Practices  for  Multimedia  Portability,  v.1.2 

1  (analog  video,  includes  MIDI) 

IMA-RP,  1993 

Informational 

(Approved) 

CPC 

IMA 

Recommended  Practice*  for  Enhancing  Digital  Audio 
Compatibility  in  Multimedia  Systems 

IMA  RP,  1992 

Informational 

(Approved) 

CPNC 

OMF 

Audio  Interchange  File  Format,  Audio  Interchange  File 
Format  Compressed  (AIFF/AIFC) 

A1FF  (BA  IFF  85) 

Informational 

(Approved) 

cpn-c 

Microaoft 

Resource  Interchange  File  Format  -  Wave  Form  Audio 
(RIFF  WAVE)  v.  1.0 

RIFF  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Creative  Labs 

SoundBlaster  Creative  Voice  File  Format  (VOC) 

VOC  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Apple 

Pulse  Code  Modulation  (PCM)  1 1.025  kHz,  8-bit,  linear 

AIFF  Version  1 
(also  IMA  RP) 

Informational 

(Approved) 

CPNC 

Afple 

Pulse  Code  Modulation  (PCM)  22.05  kHz,  8-bit,  linear 

AIFF  Version  1. 
(also  IMA  RP) 

Informational 

(Approved) 

CPC 

Varioui 

Pulse  Code  Modulation  (PCM)  44.1  kHz,  16-bit,  linear 
CD-DA  (music  CDs) 

Red  Book,  1980 
(also  IMA  RP) 

Informational 

(Approved) 

CPNC 

Intel 

Adaptive  Differential  Pulse  Code  Modulation  (ADPCM)  8- 
,  11.025-.22.05-,  44. 10-kHz,  4-bit 

DO  Documents 
(also  IMA  RP) 

Informational 

(Approved) 

CPC 

Various 

Adaptive  Differential  Pulse  Code  Modulation  (ADPCM) 
17-kHz,  4-bit  CD-XA  (Extended  Architecture) 

XA  level  B 

Informational 

(Approved) 

CPC 

Varioui 

Adaptive  Differential  Pulse  Code  Modulation  (ADPCM) 
8.5-kHz,  4-bit  CD-XA  (Extended  Architecture) 

XA  level  C 

Informational 

(Approved) 
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3.12.1.10.2  Alternative  sped  flea tions.  Many  popular  sound  cards  support  other  formate,  such  as 
2- and  4-bit  PCM. 

-U2.1.10.3  Standards  deficiencies.  No  uniform  timing  information  is  carried  with  most  audio 
interchange  formats.  Thus  synchronization  of  multiple  audio  streams  is  inherently  difficult  Also, 
sound  clips  may  have  to  be  retimed  to  SMPTE  time  codes  when  producing  broadcast  video 
output 

3.12.1.10.4  Portability  caveats.  Apple  sampling  rates  deviate  slightly  horn  the  values  given  in 
the  table  because  of  internal  clock  rates.  Therefore,  mixing  of  audio  played  back  from  two 
different  platform  types  is  difficult  This  is  true  even  among  the  same  kinds  of  platforms  because 
CPU  clocks  and  sampling  clocks  on  sound  boards  can  vary  widely. 

The  IMA's  Recommended  Practices  for  Enhancing  Digital  Audio  Compatibility  in  Multimedia 
Systems  is  a  set  of  audio  formats  that  are  guaranteed  to  be  supported  on  any  IMA  audio- 
compliant  platform.  These  formats  are  required  to  provide  baseline  digital  audio  cross-platform 
support  to  satisfy  a  range  of  audio  quality  and  data  bandwidth  requirements.  Although  the 
recommended  practice  has  gained  industry  support,  many  manufacturers  use  proprietary  ADPCM 
compression  algorithms. 

SoundBlaster  VOC  format  is  used  mainly  in  Microsoft  MS-DOS  applications.  This  is  the 
dominant  de  facto  standard  for  such  applications. 

3.12.1.10.5  Related  standards.  The  following  standards  are  related  to  digital  audio  interchange 
standards. 

a.  Microsoft  AVI 

b.  Apple  QuickTime  1.5 

c.  Apple  Bento  container  format 

3.12.1.10.6  Recommendations.  MPEG  1  audio  is  not  a  single  compression  algorithm  but  a 
family  of  three  audio  encoding  and  compression  schemes  called  MPEG-Audio  Layer-2,  and 
Layer-3,  all  three  of  which  are  hierarchically  compatiHe.  The  audio  compression  schemes  are 
lossy,  but  they  can  achieve  perceptually  lossless  quality. 

MPEG  2  audio  is  intended  to  encode  up  to  five  full  bandwidth  channels  and  additional  low- 
ffequency  enhancement  channel,  and  up  to  seven  commentary  or  multilingual  channels. 

Procurements  concerned  with  digital  audio  should  proceed  with  care.  Many  important  standards 
for  digital  audio  are  proprietary  standards. 
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3.12.1.11  Encoded  audio  interchange.  Encoded  audio  consists  of  audio  that  is  described  by  a 
language  that  is  interpreted  on  playback.  Encoded  audio  is  typically  used  for  synthesized  music. 

3.12.1.11.1  Standards.  Table  3.12-1 1  presents  multimedia  standards  for  encoded  audio 
interchange. 


TABLE  3.12-11  Encoded  audio  Interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

IMA 

Musical  Instnxncnt  Digital  Interface  (MIDI) 

MIDI  1.0 

Informational 

(Approved) 

CPC 

IMA 

MIDI  Tune  Code  and  Cueing  (supplement  to  MIDI  1.0) 

MIDI  supplement 

Informational 

(Approved) 

CPC 

IMA 

Recommended  Practices  for  Multimedia  Portability.  V.1.2 
(analog  video,  include*  MIDI) 

IMA-RP,  1993 

Informational 

(Approved) 

CPC 

VESA 

Audio  Interface  (VBE/AI)  Standard  1.0  API 

VESA  1994 

Informational 

(Approved) 

CPN-C 

Creative  Lab* 

SoundBlaster  SBK  (API) 

SoundBlaiter  Tech, 
Manuals 

Informational 

(Approved) 

CPN-C 

Microsoft 

Multimedia  Control  Interface  (MCI)  API 

MCI  API  1.0 

Infotmational 

(Approved) 

IPC 

1SO/IEC 

Standard  Music  Description  Language  (SMDL)  (An 
SGML  and  HyTime  application) 

10743:1995 

Infotmational 

(Draft) 

3.12.1.11.2  Alternative  specifications.  None 

3.12.1.11.3  Standards  deficiencies.  No  IPC,  NPC,  or  GPC  standards  exist  for  encoded  audio. 
Synchronization  and  degradation  control  are  not  well  supported  in  any  of  the  current 
environments. 

3.12.1.11.4  Portability  caveats.  Programming  models  are  generally  in  a  state  of  flux,  especially 
at  the  operating  system  level.  As  a  result,  any  code  development  will  probably  not  port,  especially 
if  performance  advantages  are  taken  in  the  imaging,  audio,  and  video  areas. 

3.12.1.11.5  Related  standards.  None. 

3.12.1.11.6  Recommendations.  Although  MIDI  is  a  CPC  standard,  it  i.,  videly  supported  by 
industry.  Given  the  near  universal  support  for  MIDI,  it  is  unlikely  that  an  alternative  will  make 
inroads  unless  the  underlying  technology  changes.  If  synthesized  music  or  sound  effects  are 
needed,  MIDI  is  recommended  as  an  interim  solution  until  an  IPC,  NPC,  or  GPC  standard  is 
available. 

Maintain  original  audio  for  archival  and  re-use  purposes. 
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3.12.2  Multimedia  programming  systems.  A  programming  system  is  defined  to  be  an 
application  or  platform  that  is  intended  to  encompass  all  the  necessary  support  to  produce  or 
playback  a  broad  range  of  multimedia  titles. 

3.122.1  Programming  platforms.  Programming  platforms  are  computer  systems  designed  to 
include  necessary  facilities  for  developing  and  displaying  multimedia  titles. 

3.122.1.1  Standards.  Table  3.12-12  presents  standards  for  programming  platforms. 


TABLE  3.12-12  Programming  platforms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

MPC  Woritiog 
Group 

Multimedia  Penooal  Computer  (MPC)  III 

MPC3, 1995 

Informational 

(Approved) 

CPC 

MPC  Working 
Group 

Multimedia  Peraonal  Computer  (MPC)  II 

MPC2, 1993 

Informational 

(Approved) 

CPC 

MPC  Working 
Group 

Multimedia  Penooal  Computer  (MPC) 

MPC,  1991 

Informational 

(Approved) 

CPN-C 

An* 

QuickTime 

QuickTime  2.5 

Informational 

(Approved) 

cmc 

Philip* 

Compact  DUc  Interactive  (CD-I) 

Green  Book,  1987 

Informational 

(Approved) 

3.122.12  Alternative  specifications.  Available  alternative  solutions  include  various  proprietary 
computer  platforms,  such  as  Silicon  Graphics  development  computers. 

3.12.2.12  Standards  deficiencies.  No  IPC,  GPC,  or  NPC  standards  exist  for  the  specification  of 
multimedia  programming  platforms. 

The  original  MPC  specification  is  insufficient  for  most  modem  multimedia  applications. 

All  systems  are  struggling  with  synchronization  accuracy  and  control  of  digital  data  streams,  both 
from  the  specification  and  implementation  points  of  view. 

Some  platform  specifications  are  minimal  and  too  incomplete  to  guarantee  interoperability  or 
portability.  Little  certification  work  is  underway  to  guarantee  compliance  to  any  of  these. 

3.122.1.4  Portability  caveats.  Byte  alignment  of  native  data  types  can  be  a  problem  when 
moving  between  platforms. 

3.12.2.12  Related  standards.  None. 

3.122.1.6  Recommendations.  Platforms  should  be  tailored  to  mission  needs.  CD-I,  which  is 
aimed  at  the  consumer  market,  is  not  recommended. 
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3.122.2  Authoring  languages.  Authoring  languages  are  languages  that  are  specifically  designed 
for  the  development  of  multimedia  applications  and  tools.  They  may  be  interpreted  or  compiled 
on  target  platforms. 

3.12.23.1  Standards.  Table  3.12-13  presents  standards  for  authoring  languages. 


J^tBI^JUJ^S^uthorjnjJangiajMrtaiidards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISOAEC 

Hypermedia/Tune- Baaed  Structuring  Language  (HyTune) 

10744:1992 

Info  relational 
(Approved) 

CPN-C 

Macro  Media 

MMLingo 

MMLingo  Tech. 
Manuals 

Informational 

(Approved) 

CPN-C 

Sybaee/Qiin 

Gain  Extern kv  Language  (GEL) 

GEL  v.2.1 

Informational 

(Approved) 

3.12.2.2.2  Alternative  specifications.  Other  authoring  and  scripting  languages  are  available. 
Many  full-featured  commercial  authoring  systems  are  available,  some  of  which  support  multiple 
platforms. 

3.12.2.2.3  Standards  deficiencies.  Deficiencies  in  the  existing  specifications  are  unknown. 

3.12.2.2.4  Portability  caveats.  Portability  problems  with  the  existing  specifications  are  unknown. 

3.12.2.2.5  Related  standards.  None. 

3.12.2.2.6  Recommendations.  HyTime  (ISO  10744)  is  the  only  IPC  standard  available  for 
multimedia  authoring  languages.  It  should  be  used  if  suitable  for  specific  title  development 
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3.11.2.3  Interchange  media.  Interchange  media  are  designed  to  deliver  finished  multimedia  tides 
to  a  broad  range  of  platforms. 

3.12.2.3.1  Standards.  Table  3. 12- 14  presents  standards  for  supporting  interchange  between 
platforms. 


TABLE  3.12-14  Interchange  media  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Data  Interchange  on  Read-Only  120mm  Optical  Data 
Disks  (CD-ROM)  (see  ECMA  130- IMS) 

10149:1995 

Adapted 

(Approved) 

IPC 

ISO/IEC 

Volume  and  Hie  structure  of  CD-ROM  for  Information 
Interchange  (fame  as  ECMA  1 19) 

9660:1981 

Adopted 

(Approved) 

GPC 

DOD  (DISA) 

Department  of  Defense  Hantfcoofc,  DOD- Produced  CD- 
ROM  Products,  lit  Revision 

MIL-HDBK- 
9660A  (1996) 

Informational 

(Approved) 

IPC 

ECMA 

Data  Interchange  on  Read-Only  120  mm  Optical  Data 
Disks  (CD-ROM) 

130(1988) 

Informational 

(Approved) 

CPC 

IMA 

Recommeoded  Practice  for  Data  Exchange  (adopts  Bento 
and  mi  OMFI  subset) 

1MA-RP,  950701.1 

Informational 

(Approved) 

CPC 

Various 

UNIPACK  (format  interface) 

P18.01-DO  141 
(5/93) 

Informational 

(Approved) 

IPC 

ISO/EC 

Coding  of  Multimedia  and  Hypermedia  Information  -  Part 

1:  MHEG  objects  representation  •  base  notation  (ASN-1), 
P%rt  4:  R ©filtration  procedure  for  MHEG  format  identifier 

13522-1,4:1995 

Informational 

(Approved) 

CPC 

Various 

CD- Rom  standard 

Yellow  Bo-jk,  1984 

Informational 

(Approved) 

CPN-C 

Microsoft 

CD-XA  (Extended  Architecture)  (media  interface  for 
interchange) 

CD-XA,  1986 

Informational 

(Approved) 

CPN-C 

Apple 

CD- WO  (Write  Once)  (media  interface  for  interchange) 

Orange  Book,  1993 

Informational 
(Approved)  j 

CPN-C 

Apple 

Bento  (Format  and  API) 

1.0d5, 1992 

Informational 

(Approved) 

CPN-C 

Avid 

Open  Media  Framework  Interchange  (OMFI)  format  and 
API 

OMFI,  V.  1.0. 1993 

Informational 

(Approved) 

CPC 

Various 

Digital  Video  Disk  (DVD) 

DVD 

Informational 

(Approved) 

CPC 

Various 

High  Density  Compact  Disc,  System  Description  v  0.5 
(MM-CD) 

Gold  Book.  1995 

Informational 

(Draft) 

CPC 

Various 

Supei  Disk  (SD) 

SD 

Informational 

(Draft) 

CPC 

X/Open 

CD-ROM  Support  Component  (XCDR) 

PI  20:5/91 

Informational 

(Superseded) 

3.12.2.3.2  Alternative  specifications.  No  other  specifications  are  available. 

3. 12.2. 3 J  Standards  deficiencies.  ISO  9660  does  not  support  long  filenames  such  as  those  used 
on  UNIX  systems. 
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3.12.2.3.4  Portability  caveats.  The  IMA  Recommended  Practice  for  Data  Exchange  has  only 
recently  been  published.  Therefore,  it  is  not  yet  broadly  supported.  It  is  designed  to  be  a 
platform-  and  content-neutral  recommendation  for  the  exchange  of  multimedia  data  for  content 
and  title  developers. 

3.12 .2.3.5  Related  standards.  The  following  standards  are  related  to  CD-ROM: 

a.  CD-R  is  a  standard  and  technology  that  allows  a  user  to  write  to  and  read  from  a 
Compact  Disc. 

b.  CD-ROM  is  a  compact  disc  format  used  to  hold  text,  graphics,  and  stereo  sound. 

c.  CD-ROM/XA  is  a  CD-ROM  enhancement  that  allows  audio  to  be  interleaved  with 
data.  It  also  functions  as  a  bridge  between  CD-ROM  and  CD-I,  since  CD- 
ROM/XA  discs  will  play  on  a  CD-I  player.  CD-ROM/XA  uses  a  standard  CD- 
ROM  player,  but  requires  a  CD-ROM/XA  controller  card  in  the  computer. 
Although  it  is  not  a  video  specification  limited  video  can  be  included  on  disc.  To 
use  it,  you  must  have  a  drive  that  reads  the  audio  portions  of  the  disc  and  an  audio 
card  in  your  computer  that  translates  the  digital  data  into  sound.  Not  all  drives  can 
recognize  the  extensions. 

d.  CD-Video  (CD-V)  is  a  format  for  putting  five  minutes  of  video  on  a  three-inch 
disc. 

e.  CD-WO  is  a  CD-ROM  version  of  the  WORM  technology.  CD-WO  discs  conform 
to  ISO  9660  standards  and  can  be  played  in  CD-ROM  drives. 

3.12.2.3.6  Recommendations.  ISO  9660  and  10149  should  be  used  for  all  CD-ROM 
applications.  ISO  9660  describes  the  logical  structure  of  information  on  a  CD.  ISO  10149 
describes  the  physical  structure  of  the  CD.  In  addition,  DISA's  Department  of  Defense  CD-ROM 
Requirements  and  Guidelines,  which  gives  DOD  labeling  and  security  requirements  dong  with 
other  information,  should  be  followed. 

MHEQ  (ISO  13522)  will  define  an  interchange  format  for  real-time  multimedia  information 
interchange.  Its  goals  are  platform  independent  interchange  of  interactive  multimedia  content, 
robust  time-space  composition  and  synchronization,  real-time  interchange,  and  incorporation  of 
arbitrary  monomedia  formats. 

Use  of  high-capacity  compact  discs  (MM-CD  and  SD)  should  be  avoided  until  a  single  standard 
has  been  agreed  upon.  Even  after  agreement,  use  should  be  considered  carefully  because 
portability  will  not  be  available  for  legacy  systems  that  do  not  support  these  discs.  An  agreement 
to  produce  a  single  standard  was  announced  at  the  time  of  this  writing. 
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3.12 3  Multimedia  presentation.  Presentation  standards  deal  directly  with  representational 
issues  of  information  and  output  devices  that  convert  digital  information  to  human  information. 
Graphical  user  interfaces  are  covered  in  detail  in  part  3  of  the  1TSG  and  are  not  included  here. 

3.12.3.1  Text  presentation.  Text  presentation  deals  with  displaying  formatted  text  and 
documents  to  appear  to  the  viewer  in  the  way  the  author  intended.  It  includes  both  the  layout  and 
typeface  of  the  text. 

3.123.1.1  Standards.  Table  3.12-15  presents  standards  for  text  presentation. 


TABLE  3.12-15  Text  presentation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/EC 

Standard  Page  Description  Language  (SPDL) 

10180:1992 

Informational 

(Approved) 

IPC 

1SO/IEC 

Documentation  Style  Semantic*  and  Specification 
Language  (DSSSL) 

10179:1995 

Informational 

(Approved) 

CPN-C 

Adobe 

Portable  Document  Format  (PDF) 

PDF 

Informational 

(Approved) 

CPN-C 

Adobe 

PostScript  Type  I  •  Outline* 

PS  Tech.  Manual* 

Informational 

(Approved) 

CPN-C 

Microsoft 

TrueType  -  Outline* 

IT  Tech.  Manual* 

Informational 

(Approved) 

3.12.3.1.2  Alternative  specifications.  Viewers  are  available  for  some  commercial  applications, 
such  as  Microsoft  Word  and  FrameMaker. 

3.12.3.13  Standards  deficiencies.  No  approved  public  standards  exist  for  text  presentation. 
3.12.3.1.4  Portability  caveats.  TrueType  is  limited  to  Microsoft  Windows. 

3.123.13  Related  standards.  HTML  is  related  to  text  presentation. 

3.12.3.1.6  Recommendations.  SPDL  deals  with  text  presentation.  These  standards  add 
formatting  information  to  SGML  for  the  presentation  of  electronic  documents.  Adobe  PDF 
supports  interchange  of  documents  including  graphics  among  Apple,  IBM  PC,  and  UNIX 
systems.  A  document  is  simply  printed  to  Acrobat,  which  produces  an  interchange  file.  The 
Acrobat  reader  is  available  at  no  charge.  Adobe  Acrobat  should  be  considered  as  an  interim 
solution.  PDF  is  used  frequently  but  suffers  by  the  fact  that  it  has  not  been  endorsed  by  an  open 
consensus  standards  body.  Efforts  need  to  be  taken  to  move  PDF  from  the  de  facto,  proprietary, 
realm  to  be  an  open  standard. 

HTML  is  a  DTD  of  SGML.  It  does  not  as  rigidly  define  the  appearance  of  HTML-tagged 
documents  as  does  SPDL  or  PDF. 
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3.12.3.2  Graphics  presentation.  Graphics  presentation  standards  deal  with  interfaces  to 
graphics  display  devices  and  environments  for  the  presentation  of  graphics  and  related  multimedia 
objects.  Note  that  in  this  instance,  graphics  presentation  includes  raster  and  vector  graphics. 

3.12.3.2.1  Standards.  Table  3.12-16  presents  standards  for  graphics  presentation. 


TABLE  3.12-16  Graphics  presentation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

CPC 

VESA 

VESA  BIOS  2.0  (SVGA  Mid  audio  comnuod  interface) 

VESA  1994 

Informational 

(Approved) 

cpn-c 

IBM 

CGA/EGA  Graphic*  (command  interface) 

CGA/EGA  1991 

Informational 

(Approved) 

CTN-C 

IBM 

VGA  Graphic*  (commend  interface) 

VGA  1992 

Informational 

(Approved) 

CPN-C 

Apple 

PICT  and  PICT32 

Apple  SDK 

Informational 

(Approved) 

CPN-C 

IBM 

XGA  Graphic*  (commend  interface) 

IBM  Tedi.  Report 

Informational 

(Approved) 

IPC 

ISO 

None 

Infoimational 

(Draft) 

3.12.3.2.2  Alternative  specifications.  None. 

3.12.3.2  .3  Standards  deficiencies.  No  approved  IPC,  GPC,  or  NPC  standards  exist  for  graphics 
presentation.  Strict  adherence  to  correct  presentation  and  output  standards  will  require  color 
calibration  equipme-t 

3.12.3.2.4  Portability  caveats.  Graphics  portability  is  generally  achieved  by  data  interchange,  not 
by  uniform  cross-platform  display  standards.  Source  material  may  be  visually  impaired  through 
use  of  low  quality  displays.  Vector  and  raster  graphics  that  require  high  resolutions  and  large 
color  spaces  will  be  less  portable. 

3.123.23  Related  standards.  None. 

3.12.3.2.6  Recommendations.  There  is  no  recommendation  at  this  time. 
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3.I2JJ  Color  definition.  (This  BSA  appears  in  part  5,  Data  Interchange,  part  12,  Multimedia, 
and  part  13,  Human  Factors.)  Color  definition  deals  with  establishing  a  reference  base  for 
identifying  colors  to  aid  in  the  matching  and  exchange  of  color.  Color  definition  standards  apply 
to  defining  color  in  general,  and  not  only  to  color  definition  for  information  technology  systems. 

3.12.3  J.I  Standard.  Table  3.12-17  presents  standards  for  color  definition. 


TABLE  3.12-17  Color  definition  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ASTM 

Standard  Test  Method  for  Computing  the  Coion  of  Objects 
by  Using  the  CIE  System 

E308  (1990) 

informational 

(Approved) 

NPC 

HA 

1976  C1E-UCS  Chromaticity  Diagram  with  Color 
Boundaries 

TEB26  (1988) 

Informational 

(Approved) 

IPC 

ISO 

CIE  Standard  Colorimetric  DJuminants 

CIE  10526(1991) 

Informational 

(Approved) 

IPC 

ISO 

CIE  Standard  Colorimetric  Observers 

CIE  10527  (1991) 

Infotmational 

(Approved) 

IPC 

CIE 

Recommendations  on  Uniform  Color  Spaces,  Color- 
Difference  Equations,  and  Psydmxnetric  Color  Terms 

CIE  Pub.  l5.Suppl. 
2(1986) 

Informational 

(Approved) 

NPC 

NPESA 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Arts  Prepress  Definition  of  Default  RGB  Data  for 
Use  in  the  Graphic  Arts  Industry 

N/A 

SMPTE/BIA/VE 

SA/ISO 

Unreferenced  24- bit  RGB 

Technical  Reports 

Informational  1 
(Approved) 

IPC 

ISO/ffiC 

Teat  and  Office  Systems  Colour  Architecture  (TQSCA) 

JTC1/5C18/WGS 

Informational 

(Draft) 

CPC 

ICC 

Definition  of  Named  Color 

TBD 

Informational 

(Formative) 

NPC 

ANSI  IT8  and 
CGATS 

Specifications  for  Web  Offset  Publications  (SWOP) 

TBD 

Informational  9 
(Formative)  j 

The  CDE  (International  Commission  on  Illumination)  is  the  principal  international  standards 
writing  body  for  agreements  for  color,  vision,  and  illumination.  Under  ANSI,  four  bodies  work  on 
color-related  standards.  ANSI  X3  works  on  office  document  automation  and  information  systems. 
ANSI  IT8/CGATS  is  concerned  with  graphic  arts.  ASTM  deals  with  color  metrology  and 
standard  practices,  and  SMPTE  handles  standards  for  color  television  and  color  monitors. 

ANSI's  Committee  for  Graphic  Arts  Technology  Standards  (CGATS)  has  eight  subcommittees 
working  on  topics  such  as  materials  handling,  process  control,  and  color  data  definition.  NPESA 
is  the  National  Printing  Equipment  and  Supply  Association. 

3.12.3.3.2  Alternative  specification.  The  following  alternative  specifications  are  also  available: 
a.  Pantone  Matching  System 
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b.  RGB  (Red,  Green,  Blue)  -  the  method  directly  used  by  color  video  display 
terminals 

c.  CMYK  (Cyan,  Magenta,  Yellow,  Black)  -  used  in  four  color  printing 

d.  HSV  (Hue,  Saturation,  V.) 

e.  HSL  (Hue,  Saturation,  Luminescence) 

f.  HVC 

g.  SWOP  (Specifications  for  Web  Offset  Publications) 

h.  HSB  (Hue,  Saturation,  Brightness) 

L  TIFF  (Tag  Image  File  Format) 

3.123.3  3  Standard  deficiencies.  Comparison  of  color  defined  by  the  existing  standards  assumes 
identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons  across 
viewing  environments,  althou^  nodels  are  being  worked  on.  Strict  adherence  to  correct 
presentation  and  output  standards  will  require  color  calibration  equipment 

3.123.3.4  Portability  caveats.  Translation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  bust  There  are  three  different ~  dor  definitions 
from  the  CIE.  They  are  the  CIEXYZ  tristimulus  values,  and  the  CIELAL  ai'ri  CIELUV  color 
spaces.  These  standards  have  existed  for  a  long  time  and  are  seen  as  the  common  basis  for  any 
future  unifying  definitions. 

There  are  also  the  problems  of  color  matching.  For  example,  of  1012  Pantone  colors  for  coated 
paper,  70  cannot  be  reproduced  in  the  CMYK  definition.  CIEXYZ  is  useful  in  comparing  colors 
under  identical  viewing  conditions.  CIEXYZ  has  a  rigorous  definition  and  by  itself  does  not 
necessarily  constitute  a  complete  color  specification.  CIEXYZ  is  a  standardized  set  of  primaries 
which  are  not  physically  realizable  bu  t  can  match  all  possible  colors  with  entirely  positive 
tristimulus  values.  A  new  form  of  color  definition  is  emerging,  known  as  high-fidelity  color.  The 
idea  behind  high-fidelity  color  is  the  use  of  five  to  seven  different  colors  in  the  printing  process  to 
wi„en  the  ranre  of  colors  that  can  be  printed.  Two  such  models  that  have  appeared  are  the 
K"nper  set  which  increases  the  number  of  printed  colors  in  the  blue  region  by  80%,  and  the  VSF 
model  which  provides  better  performance  in  deep  red  and  green  colors.  These  processes  are  very 
non-standard  and  should  be  avoided  at  prese.it. 

Common  systems  typically  do  not  support  colorimetric  calibration. 

3.123.3.5  Related  standards.  The  following  types  of  standards  are  related  to  standards  for  the 
definition  of  color: 
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a.  color  matching  stusidards 

b.  color  data  exchange  standards 

c.  color  uae  standards 

d.  style  guide  standards 

3.1233.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  Maintain  original  copies  of  source  material  so  that  revisions  can  be  produced 
for  next  generation  systems  that  will  allow  the  inclusion  of  calibration  information. 
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3.12.3.4  Audio  presentation.  Audio  presentation  standards  deal  with  interfaces  for  audio 
playback, 

3. 12.3.4.1  Standards.  Table  3.12-18  presents  standards  for  audio  presentation. 


TABLE  3.12-18  Audio  presentation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Statue 

DoD 

(Lifecycle) 

CPC 

VESA 

VESA  BIOS  10  (SVGA  mi  audio  oonoiaad  iotccface) 

VESA  1994 

hfiiniMMiiil 

CPC 

Vdiioot 

Pub*  Co*  MofeMha  (PCM)  44.1  kH*.  ltbfcfettr 
CD-DA  (dmwc  CD*) 

Rjd  Book.  1910 
(iboIMAJtP) 

bfoBMtMMl] 

(Anaamd) 

CPN-C 

A»t. 

Pub*  Code  IdodokRarm  (PCM)  22.05  kHz,  l-bk,  law 

AffPVonfaa  1. 
(obo  IMA  RP) 

bfoMUtbOOdl 

(Affomd) 

CPN-C 

CroddmLabi 

SoMdSkiUr  SBK  (API) 

SofflBlirtef  Took. 

UoMbioMl 

(Afpond) 

3.1 13.42  Alternative  specifications.  None. 

3.12J.4J  Standards  deficiencies.  No  IPC,  GPC,  or  NPC  standards  exist  for  audio  presentation. 
Strict  adherence  to  correct  display  and  output  standards  will  require  audio  calibration  equipment. 

3.12J.4A  Portability  caveats.  Source  material  may  be  aurally  impaired  through  use  of  low- 
quality  amplifiers  and  speakers.  Calibration  information  that  allows  a  user  to  correctly  set  audio 
levels  at  the  beginning  of  a  title  can  substantially  enhance  a  presentation. 

3.12.3.4.5  Related  standards.  None. 

3.12.3.4.6  Recommendations.  Maintain  original  copies  of  source  materials  for  re-use  when  IPC, 
GPC,  and  NPC  standards  become  available. 
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3.1225  Monitor*.  Monitor  standards  specify  the  electrical  and  display  characteristics  of 
computer  and  televisiu.  monitors. 

3.123.5.1  Standards.  Table  3.12-19  presents  standards  for  monitors. 


TABLE  3.12-19  Monitors  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-R 

OMdactafUtict  of  Tetevinoo  Syrian*  -  Chororuriitica  of 
Syrtaou  for  Monochrome  *od  Coktur  Televiskn 

Report  624-4: 1990 

Info  matronal 
(Appmywt) 

IPC 

EC 

PWm  Akernebnf  Line  (PAL)  for  teievinon  (znelot  video) 

1146 

hfoandiontl 

(Approved) 

CPC 

VESA 

Monitor  T«Mf  Staadmd  foe  *00  *  600  72Hz  and  1024  * 
761 70Hz  nfrah  rate 

VESA  1993 

lofo  matronal 
(Approved) 

CPC 

VESA 

Monitor  Timiac  Manufacture*  Guideline  for  1024  x  766 
with  60  Hz,  100*600  with  60Hz.  100*600  with  56Hz 
rafrrahrate 

VESA  1993 

Informational 

(Approved) 

CPC 

NTSC 

15.73423kHz  Scan  Specific***  (TV  Monitor) 

NTSC-Y1Q 
Standard  (I9<0) 

InfotmationaJ 

(Approved) 

NPC 

SMPTE 

Studio  Monitor  Specification  (Phoaphor  Interface) 

SMPTE  C.D60, 
D65 

Infotmational 

(Approved) 

NPC 

SMPTE 

Basx  pnametorviluM  for  d w  HDTV  lUndfird  for  the 
atudio  and  for  into  mititirel  programme  eidrange 

Roc.  709 

International 

(Approved) 

NPC 

SMPTE 

Teteviraon  -  Signal  Parameter*  - 1 1 25/60  High-Dcfioitiaa 
Production  Synem  (TV  Monitor) 

SMPTE  Standard 
240M.  19tt 

International 

(Approved) 

NPC 

SMPTE 

Tateviaioo  •  Digital  RapreMetalioe  and  Bit-Parallel 
Intarfana  -  11 25/60  High-  Defwboa  Production  Syatem 
(TV  monitor) 

SMPTE  Standard 
260M,  1992 

leSofmatKMuJ 

(Approved) 

3.12252  Alternative  specifications.  None. 

3.12252  Standards  deficiencies.  Strict  adherence  to  correct  display  and  output  standards  will 
require  audio  and  color  calibration  equipment 

3.1225.4  Portability  caveats.  Source  material  may  be  visually  impaired  through  use  of  low 
quality  monitors.  Calibration  information  that  allows  a  user  to  correctly  set  monitor  levels  at  the 
beginning  of  a  title  can  substantially  enhance  a  presentation. 

3.12255  Related  standards.  None. 

3.1225.6  Recommendations.  Use  the  established  standards  given  above  for  computer  and 
television  monitors.  Avoid  development  for  high-definition  television,  which  is  now  a  formative 
technology. 
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3.12.3.6  Embedded  time  codes.  Embedded  time  codes  provide  timing  information  within  data 
streams.  They  are  necessary  for  proper  synchronization  in  the  presentation  of  multimedia. 

3.12.3.6.1  Standards.  Table  3.12-20  presents  standards  for  oubedded  time  codes. 


TABLE  3.12-20  Embedded  time  codes  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

SMPTE 

Tdcvitioa.  Audio,  tod  Film  -  Storage  nod  Trantturion  of 
Data-  Binary  Group*  of  Time  and  Control  Code* 

262M 

lnfftmuiumal 

(Approved) 

3.12.3.6.2  Alternative  specifications.  Proprietary  timing  and  synchronization  control  codes  are 
used  in  some  environments. 

3.123.63  Standards  deficiencies.  None. 

3.12.3.6 A  V'/'tability  caveats.  None. 

3.12.3.6  r  '  ••ird  At.  >A.;rds.  None. 

3.12 .3.6.6  Recom..’.:  :  ’  .ns.  Use  SMPTE  262M. 
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3.12.4  Video  and  audiographic  teleconferencing.  Video  teleconferencing  is  the  live 
transmission  of  audio  and  video  over  a  network  among  two  or  more  users.  Audiographic 
teleconferencing  (AGT)  lets  conference  participants  manipulate  documents  and  other  data 
collectively  with  accompanying  real-time  audio.  Many  VTC  and  AGT  standards  deal  with 
audio/video  network  services.  Only  those  standards  directly  related  to  multimedia  data  formats 
are  presented  below.  Transmission  protocols,  transfer  protocols,  and  security  standards  are  not 
included. 

3.12.4.1  Video  and  audiographic  teleconferencing. 

3.12.4.1.1  Standard.  Table  3.12-21  presents  standards  for  video  and  audiographic 
teleconferencing. 


TABLE  3.12-21  Video  and  audiographic  teleconferencing  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Industry  Profile  for  Video  Teleconferencing 

VTC001.  Revision 

1.  April  25.  1995 

Mandated 

(Approved) 

IPC 

ITU-T 

Termind  for  Low  Bit  Rile  Multimedia  Communication*. 
March  19. 1996 

H.324 

Mandated 

(Approved) 

GPC 

NIST 

Video  Teleconferencing  Service*  *1 56  to  1 , 920  KB/* 
(adopt*  CCITT  H.221,  H.230.  H.242.  H.26I,  and  H.320 
(all  1990)) 

FIPS  PUB 
178:1992 

Informational 

(Approved) 

IPC 

ITU-T 

Pulse  Code  Modulation  (PCM)  of  voice  frequencies 
(narrowband) 

0.711:1989 

Liformational 

(Approved) 

IPC 

rru-T 

Transmission  performance  characteristics  of  pulse  code 
modulation 

0.712(1992) 

Informational 

(Approved) 

IPC 

rru-T 

7  KHz  Audio  Encoding  within  64  kbit/*  (broadband) 

0.722(1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Extension*  of  0.721  to  24  and  40  kbit/s  for  Digital  Circuit 
Multiplication  Equipment  Application 

0.723(1989) 

Informational 

(Approved) 

IPC 

ITU-T 

Sy  item  Aspects  of  the  Use  of  7  kHz  Audio  Codec  Widiin 

64  kbit/s 

0.725(1989) 

Informational 

(Approved) 

IPC 

ITU-T 

40. 32, 24.  and  16  kbit/s  Adaptive  Digital  Pulse  Code 

Modulation  (ADPCM) 

0.726(1990) 

Informational 

(Approved) 

IPC 

ITU-T 

0.726A  (1994) 

Informational 

(Approved) 

IPC 

ITU-T 

5. 4. 3.  and  2  bits  Sample  Embedded  ADPCM 

0.727(1990) 

Informational 

(Approved) 

IPC 

ITU-T 

Extensions  of  Recommendation  0.727  on  5-.  4-,  3-  and  2- 
bits/sampie  embedded  Adaptive  Differential  Pulse  Code 
Modulation  for  use  with  uniform-quantized  input  and 
output 

G.727A  (1994) 

Informational 

(Approved) 

IPC 

ITU-T 

Coding  of  Speech  at  16  kbiu/s  using  Low-Delay  Code 
Excited  Linear  Prediction  (LD-CELP). 

G. 728: 1992 

tnfoimaiional 

(Approved) 

IPC 

ITU-T 

Codecs  for  videoconferencing  using  primary  digital  group 
transmission 

H.I20 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ITU-T 

Video  Codoc  for  Audioviual  SorvioM  at  p  x  64  kbit/*  - 
Line  Tnruraiittoo  on  Nan-Telephone  Sign*)*  (known  u 
PX64) 

H.261  (1993) 

Informational 

(Approved) 

[PC 

ITU-T 

Coded  Rffrutotsfinn  of  Picture  and  Audio  information  - 
Prog  rose  ve  Bi-Level  kuge  Compression  -  Terminal 
Equiomeot  and  Protocol*  for  Telematic  Service* 

T.82  (1993) 

Informational 

(Approved) 

IPC 

ITU-T 

Information  Technology  -  digital  compression  and  coding 
of  continuous-tone  Mill  imagea:  compliance  teating 

T.83 

Informational 

(Approved) 

IPC 

rru-T 

Binary  Hie  Transfer  Foiraat  for  the  Telematic  Service* : 
Terminal  Equipment  and  Protocols  for  Telematic  Services 

T.434  (1992) 

InfoimctionaJ 

(Approved) 

IPC 

ITU-T 

Tranamiiaion  protocols  for  multimedia  data 

T.I20 

Informational 

(Approved) 

IPC 

itu-t 

VTC  over  ATM 

H.321 

Emerging 

(Approved) 

IPC 

rru-T 

VTC  over  Ethernet 

H.323 

Emerging 

(Approved) 

OPC 

NIST 

Video  Teleconferencing  Services  at  56  to  1920  kW> 
(Adopts  ITU  H.320,  H.221,  H.242,  H.230,  H.26I,  H.231. 
H.243.  H.2'3.  H.234.  H.244) 

PIPS  PUB  178-1 

Informational 

(Draft) 

IPC 

rru-T 

G.773 

Informational 

(Draft) 

IPC 

ITU-T 

esissi 

H.262 

Informational 

(Draft) 

IPC 

ITU-T 

Video  coding  for  low  bit  rale  communications 

H.263 

Informational 

(Draft) 

Si 

ISO/IEC 

Qervenc  Modvig  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG2)  Part  4:  Compliance  Teating 

13118-4 

Emerging 

(Draft) 

Bi 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  A*»ocialed  Audio 
Information  (MPEG  2),  Part  5:  Software  Simulation 

13818-5 

Informational 

(Draft) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  6:  Extensions  for  DSM-CC 

13818-6 

Informational 

(Draft) 

IPC 

ISO/IEC 

Generic  Coding  of  Moving  Pictures  and  Associated  Audio 
Information  (MPEG  2),  Part  7:  Audio  Extensions 

13818-7:1993 

Informational 

(Draft) 

OPC 

DOD 

Interoperability  and  Performance  Standard  for  VTC 
(superseded  by  COS  VTCOOl-Rev.t) 

MIL-STD- 188-331 
and  33 1  -A 

Informational 

(Superseded) 

3.12.4.1.2  Alternative  specification.  ISO  and  the  ATM  Forum  are  working  on  standards  for 
high-bandwidth  teleconferencing,  especially  over  ATM  networks. 


3.12.4.1.3  Standard  deficiencies.  None  of  the  ITU  teleconferencing  standards  work  well  over 
Ethernet  and  TCP/IP  networks  because  of  bandwidth  limitations. 

3.12.4.1.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 


3.12.4.1.5  Related  standards.  MPEG1  (ISO/IEC  1 1 172)  and  MPEG2  (ISO/IEC  13818)  are 
related  to  video  and  audiographic  teleconferencing.  Various  ITU  H,  G,  and  T  series  standards  are 
related  to  architecture,  equipment,  transmission  protocols,  transfer  protocols,  and  security. 
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3.12.4.1.6  Recommendations.  MIL-STD- 188-331  and  MIL-STD-188-331A  have  been 
superceded  by  the  Industry  Profile  for  Video  Teleconferencing,  VTCOOl-Rev.  1,  which  is 
mandated  for  DOD  by  the  OASD.  Because  of  differences  in  network  band  widths  and  transmission 
limitations,  video  and  audio  standards  should  be  chosen  to  fit  individual  VTC  system  capabilities. 
For  example,  ITU  G.71 1  should  be  used  for  narrow-band  speech,  while  G.722  should  be  used  for 
wide-band  speech.  FIPS  PUB  178-1  will  replace  the  VTC001  profile,  but  is  still  indraft  at  this 
writing. 
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3.13  Human  Factors.  Human  factors  (ergonomics)  is  the  science  of  determining  proper  relations 
between  computer  systems  and  the  user.  Ease  of  use,  comfort,  health,  and  safety  are  primary 
concerns  (e.g.,  how  a  keyboard  should  be  laid  out).  An  etgonomically-designed  product  implies 
that  the  device  blends  smoothly  with  the  user's  body  or  actions.  For  computing  systems,  these 
standards  provide  guidelines  and  requirements  for  the  design  of  computer  hardware,  software  user 
interfaces,  and  computing  environments. 

3.13.1  Human  factors  for  computer  hardware.  Human  factors  requirements  for  computer 
hardware  concern  the  user's  physical  interface  through  input  devices  and  displays  and  how  well  it 
serves  the  needs  of  the  user.  Health  and  safety  concerns  are  also  addressed. 

3.13.1.1  Human  factors  for  video  display  terminals.  (This  BSA  appears  in  both  part  3,  User 
Interface,  and  part  13,  Human  Factors.)  This  base  service  area  addresses  the  human  factors 
requirements  for  all  types  of  video  displays,  and  includes  safety  concerns. 

3.13.1.1.1  Standards.  Table  3.13-1  presents  human  factors  standards  for  video  display  terminals. 


TABLE  3.13-1  Human  factors  for  video  display  terminals  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  V i«unl 
DiipUy  Terminals  (VDTs)  Part  1 :  Introduction 

9241-1:1992 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 
Display  Terminals  (VDTs)  Past  2:  Task  Requirements 

9241-2: 1992 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Requirements  for  Office  Work  with  Visual 

Display  Terminals  (VDTs)  Part  3:  Visual  Display 
Requirements 

9241-3:1992 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Di^lay  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  sod  Facilities 

MIL-STD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

IPC 

ECMA 

136  (1989) 

informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principles  in  the  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 

NPC 

ANSI/AIIM 

Electronic  Imaging  Output  Displays 

TR19-1993 

Informational 

(Approved) 

CPC 

NSC 

Guide  to  Working  Safely  with  Computers  -  Manual  (relates 
u>  VDTs) 

13068-0000 

Informational 

(Approved) 

IPC 

ECMA 

Procedure  for  Measurement  of  Emissions  of  Electric  and 
Magnetic  Fields  from  VDDs  from  5  Hz  to  400  kHz' 

172(1992) 

Informational 

(Approved) 
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Standard 

Type 


Sponsor 


DOD  Instruction  (DODI)  8120  mandates  use  of  the  DOD  HCI  Style  Guide. 

AUM  is  the  Association  for  Image  and  Information  Management 
ECMA  is  the  European  Computer  Manufacturers'  Association. 

HFS  is  the  Human  Factors  Society. 

NSC  is  the  National  Safety  Council. 

ISO  9241-1  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO  9241  standard.  A 
revised  version  of  ISO  924 1  - 1  is  currently  at  the  Committee  Draft  (CD)  level  and  will  soon  be 
released  for  Draft  International  Standard  (DIS)  ballot.  ISO  9241-2  presents  an  overview  of 
factors  that  should  be  considered  when  designing  tasks  to  be  performed  in  a  specific  computing 
environment 

3.13.1.1.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.13.1.1.3  Standards  deficiencies.  The  performance-based  test  described  in  ISO  9241-3 
adequately  discriminates  between  a  display  that  meets  the  physical  requirements  of  the  standard 
and  one  that  does  not.  However,  timing  scores  may  be  badly  affected  by  the  effects  of  testing 
practice.  Changes  to  the  test  method  and  metrics  are  under  consideration.  ISO  9241-3  does  not 
adequately  address  flat  panel  displays.  ISO  13406  is  intended  to  remedy  this  situation. 

3.13.1.1.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 

3.13.1.1.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
video  display  terminals: 

a.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load,  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

b.  MIL-STD- 1 908  ( 1 992)  Definition  of  Human  Factors  T erms. 

c.  MIL-STD-1794  ( 1986)  Human  Factors  Engineering  Program  for  1CBM  Systems. 
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d.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems  (Air  Force  published,  but  rarely  used,  duplicates  M1L-STD-1472). 

e.  MIL-HDBK.-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

f.  MIL-HDBK.-761A(1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

g.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

h.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

L  ITU-T  E.  134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

j.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.13.1.1.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  computer  displays.  Display 
characteristics  include  brightness  and  contrast,  character  legibility,  image  stability,  glare,  and  the 
use  of  color. 

Note,  however,  that  ISO  human  factors/ergonomics  standards  are  either  normative  or  informative. 
An  informative  standard  contains  no  mandatory  requirements.  A  normative  standard  contains  one 
or  more  requirements  that  must  be  met  in  order  to  achieve  conformance  with  the  standard. 

ISO  9241-1  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO  9241  standard.  A 
revised  version  of  ISO  9241-1  is  currently  at  the  Committee  Draft  (CD)  level  and  will  soon  be 
released  for  Draft  International  Standard  (DIS)  ballot.  ISO  9241-2  presents  an  overview  of 
factors  that  should  be  considered  when  designing  tasks  to  be  performed  in  a  specific  computing 
environment 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative.  Part  3  of  the  ISO  9241  standard  is 
normative;  parts  2-9  are  expected  to  be  normative  on  completion.  Conformance  requirements  for 
each  normative  part  are  embedded  within  that  part  Conformance  with  the  overall  ISO  9241 
standard  is  based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modern  human  factors/ergonomic  thinking.  In  genera!, 
conformance  tests  for  informative  parts  will  not  be  available. 
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The  ISO  and  ISO/IEC  standards  cited  in  the  gray  area  of  the  table  are  being  balloted  and  revised 
at  a  rapid  rate.  Interested  parties  should  monitor  the  progress  of  these  standards  at  six  month 
intervals  to  ensure  they  have  the  latest  information.  Offerers  of  products  meeting  existing  or 
emerging  standards  should  be  required  u.  provide  a  migration  plan  to  ensure  compliance  of  the 
products  with  the  final  standards  documents. 

The  DOD  HCI  Style  Guide  is  recommended,  in  particular  section  3,  which  deals  with  hardware. 
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3.13.1.2  Human  factors  for  keyboards.  (This  BSA  appears  in  both  part  3,  User  Interface,  and 
part  13,  Human  Factors.)  This  BSA  covers  keyboard  layout,  including  specific  directions  for 
layout  of  regions  of  the  keyboard,  and  keyboard  design.  Ease  of  use  and  correct  ergonomic  design 
also  are  a  part  of  this  BSA. 

3.13.1.2.1  Standards.  Table  3.13-2  presents  human  factors  standards  for  keyboards. 


TABLE  3.13-2  Human  factors  for  keyboards  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human-Computer  Interface  (HO)  Style  Guide 

TAFIM  Vdiane  8, 
Version  3.0?  1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  1: 
General  principle*  governing  keyboard  layout 

9995-1:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  System*  Part  2: 
Alphanumeric  section 

9995-2:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  3: 
Common  secondary  layout  of  the  alphanumeric  section 

9995-3:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  4: 
Numeric  seed  on 

9995-4:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  fori  ext  and  Office  Systems  Part  5: 
Editing  section 

9995-5:1994 

Informational 

(Approved) 

IPC 

ISO/TEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  6: 
Function  section 

9995-6:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  7: 
Symbols  used  to  represent  functions 

9995-7:1994 

Informational 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  Systems  Part  8: 
Allocation  of  Letters  to  the  Keys  of  a  Numeric  Keyboard 

9995-8:1994 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstation* 

100-1988 

Informational 

(Approved) 

NPC 

ANSI 

Coded  Character  Sets  for  Keyboard  Arrangement  in  ANSI 
X4.23-1982  and  X4.22- 1983 

X3.1 14-1984 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Keyboard  Arrangement 

X3. 154- 1988 

Informational 

(Approved) 

NPC 

ANSI 

Alternate  Keyboard  Arrangement 

X3.207-1991 

Informational 

(Approved) 

GPC 

DOD 

Military  Standard  Keyboard  Arrangements 

MIL-STD-I280, 
Notice  1. 1969 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Cntei'A  tor  Military  Systems, 
Equiixnent  *r.d  Facilities 

MIL-STD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

IPC 

IEC 

Man- Machine  Interfere  (MMJ)  .  At.  orating  Principles 

447:1993 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma  Disorders:  a  Manual  for 
Musculoskeletal  Diseases  of  the  Upper  Limbs 

12221-0000 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principles  in  the  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

NPC 

ACGIH 

Ergonomic  Interval  boo*  to  Prevent  MtuculodkelcOl 
Injunct  in  Industry 

9000:1987 

Informational 

(ARUDved) 

CPC 

NSC 

Evaluating  Your  Workplace:  Hands  A  Anns  -  Ergooomic 
Changed  Manual 

12587-0004 

Informational 

(Approved) 
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DODI 8120  mandates  use  of  the  DOD  HCI  Style  Guide. 


The  ANSI  X3.154  standard  specifies  the  customary  "QWERTY"  keyboard  arrangement.  The 
ANSI  X3.207  standard  specifies  the  "DVORAK"  keyboard  arrangement.  ACGIH  is  the  American 
Conference  of  Governmental  Industrial  Hygienists. 

3.13.1.2.2  Alternative  specifications.  There  are  no  alternative  specifications  available. 

3.13.1.2 3  Standards  deficiencies.  MDL-STD-  1472D  is  in  need  of  a  comprehensive  revision  to 
update  technical  material  so  that  it  is  reasonably  consistent  with  the  state  of  the  art  and  to  ensure 
that  the  two  commands  not  currently  using  the  standard  can  do  so. 

3.13.1.2.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 

3.13.1.2.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
keyboards: 

a.  ISO  924 1  - 1 : 1992,  Ergonomic  requirements  for  office  work  with  visual  display 

terminals  (VDTs),  part  1:  Introduction.  pr'r.ents  an  overview  of  the  content  and 
usage  of  the  multipart  ISO  9241  star  ’s.  *.  revised  version  of  ISO  9241-1  is 

currently  at  the  CD  level  and  will  soon  ue  released  for  DIS  ballot. 

b.  ISO  9241-2: 1992,  Ergonomic  requirements  for  office  wc  with  VDTs,  part  2: 
Task  Requirements,  presents  an  overview  of  factors  that  should  be  considered 
when  designing  tasks  to  be  performed  in  a  specific  computing  environment. 

c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  —  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

d.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terns. 

e.  MIL-STD- 1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 
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f.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  7590  is  complete.) 

h.  MIL-HDBK-761A(1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

L  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

j.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

k.  ITU-T  E.134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

L  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.13.1.2.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  keyboards.  Keyboard 
characteristics  include  keyboard  height  slope,  profile,  surface  properties,  adjustability,  bounce 
and  character  repeat  key  positioning,  key  displacement  and  force,  keytop  shape,  and  keytop 
legends. 

Parts  1  and  2  of  the  ISO  9241  standard  (see  related  standards)  are  informative.  Parts  2-9  are 
expected  to  be  normative  on  completion.  Conformance  requirements  for  each  normative  part  are 
embedded  within  that  part  Conformance  with  the  overall  ISO  9241  standard  is  based  on 
conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

Parts  1-8  of  the  ISO/IEC  9995  standard  are  normative.  Conformance  requirements  for  each 
normative  part  are  embedded  within  that  part.  Conformance  with  the  overall  ISO  9995  standard  is 
based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 

The  DOD  HCI  Style  Guide  is  recommended,  particularly  for  section  3,  which  covers  hardware. 
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3.13.1 3  Human  factors  for  non-keyboard  input  devices.  (This  BSA  appears  in  both  part  3, 
User  Interface,  and  part  13,  Human  Factors.)  This  section  presents  human  factors  standards  for 
input  devices  other  than  keyboards.  These  devices  include  trackballs,  pens,  and  tablets  among 
others. 

3.13.1.3.1  Standards.  Table  3.13-3  presents  human  factors  standards  for  non-keyboard  input 
devices. 


TABLE  3.13-3  Human  factors  for  non-keyboard  input  devices  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human-Computer  Interface  (NCI)  Style  Guide 

TAF1M  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

ISO/IEC 

Keyboard  Layout  for  Text  and  Office  System*  Part  7 : 
Symbols  used  to  represent  functions 

9995-7:1994 

Informational 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

IPC 

IEC 

Man-Machine  Interface  (MMI)  •  Actuating  Principles 

447:1993 

Informational 

(Approved) 

0C 

ISO 

Ergonomic  Principles  in  the  Design  of  Work  Systems 

6385:1981 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma  Disorders:  a  Manual  for 
Musculoskeletal  Diseases  of  the  Upper  Limbs 

12221-0000 

Informational 

(Approved) 

CPC 

NSC 

Evaluating  Your  Workplace:  Hands  A.  Anns  -  Ergonomic 
Changes  Manual 

12587-0004 

Informational 

(Approved) 

CPC 

NSC 

Cumulative  Trauma 

15229-0000 

Informational 

(Approved) 

NPC 

ACGIH 

Ergonomic  Interventions  to  Prevent  Musculoskeletal 
Injuries  in  Industry 

9000:1987 

Informational 

(Approved) 
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DODI  8120  mandates  use  of  the  DOD  HCI  Style  Guide. 

3.13.1.3.2  Alternative  specifications.  There  are  no  alternative  specifications  available.  Research 
in  this  area  includes  a  foot  operated  control  for  the  cursor  when  the  hands  are  occupied 
(nicknamed  a  "mole"  in  obvious  derivation  from  "mouse"). 

3.13.1.3.3  Standards  deficiencies.  Deficiencies  in  the  cited  standards  are  not  known. 

3.13.1.3.4  Portability  caveats.  No  portability  problems  are  known  with  the  above  specifications. 
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3.13.1-3.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
non-keyboard  input  devices: 

a.  ISO  9241-1:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  1: 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
9241  standard.  A  revised  version  of  ISO  9241-1  is  currently  at  the  CD  level  and 
will  soon  be  released  for  DIS  ballot 

b.  ISO  9241-2:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  presents  an  overview  of  factors  that  should  be  considered 
when  designing  tasks  to  be  performed  in  a  specific  computing  environment 

c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  —  Tart  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

d.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terms. 

e.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

f.  MEL-STD- 1 800 A  ( 1 990)  Human  Engineering  Performance  Requirements  for 
Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

h.  MIL-HDBK-761A  (1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

i.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

j.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

k.  ITU-T  E.  134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

l.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.13.1.3.6  Recommendations.  Procurements  that  require  hardware  components  to  be  addressed 
by  ergonomic  standards  can  require  conformance  with  standards  for  non-keyboard  input  devices. 
Ergonomic  issues  for  non-keyboard  input  devices  include  keyclick,  tracking  speed,  and  on-screen 
ghosting  of  the  pointer. 
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Parts  1  and  2  of  ISO  9241  are  informative.  Parts  2-9  are  expected  to  be  normative  on  completion. 
Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product.  Parts  1-8  of  ISO/IEC  9995  are  normative.  Conformance 
with  the  overall  ISO  9995  standard  is  based  on  conformance  with  all  normative  parts  that  apply  to 
a  particular  product  Part  1  of  the  ISO/IEC  10741  standard  is  expected  to  be  normative  on 
completion. 

Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  tire  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  DOD  HCI  Style  Guide  is  recommended  particularly  for  section  3,  which  covers  hardware. 
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3.13.2  Human  factors  for  software  user  interfaces.  This  Mid  level  service  area  deals  with 
human  factors  requirements  for  the  software  portion  of  the  user  interface. 


3.13.2.1  Graphical  user  interface  style  guides.  A  GUI's  style  guide,  which  is  part  of  the 
presentation  management  layer  in  the  NISTs  User  Interface  Reference  Model,  specifies  a 
standard  "look"  for  the  GUI  of  an  application  to  the  user. 

3.13.2.1.1  Standards.  Table  3.13-4  presents  graphical  user  interface  style  guides. 


TABLE  3.13-4  Graphical  user  interface  style  guides  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

OPC 

DOD 

Human-Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif  Style  Guide 

Motif  SG  Rev. 
1.2:1992 

Mandated 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Viauai  Diaplay  Terminal  Workstations 

100-1988 

Infoimational 

(Approved) 

IPC 

NATO 

Principle*  of  Presentation  of  Information  in  Aircrew 
Stabona 

STANAG  3705 

Information*] 

(Approved) 

GPC 

DOD 

User/Computer  Interface 

MIL-STD-1801  29 
May  1987 

Informational 

(Approved) 

OPC 

DOD 

Human  Engineering  Performance  Requirement!  for 
Syitcnu 

MIL-STD- 1 800 A 

10  Oct.  1990 

Infoimational 

(Approved) 

OPC 

DOD 

DOD  Handbook,  Human  Engineering  Guideline*  for 
Management  Information  Systems 

MIL-HDBK-761A 
30  Sep.  1989 

Informational 

(Approved) 

OPC 

DOD 

Guideline*  for  Designing  liter  Interface  Software 

ESD-TR-86-278 

Informational 

(Approved) 

GPC 

DOD 

Air  Force  Intelligence  Data  Handling  System  (TDHS)  Style 
Guide 

Informational 

(Approved) 

GPC 

DOD 

Human  Factors  Guidelines  for  the  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier-Machine 
Interface 

ATCCS  Guidelines 
v.  1.0  and  v.2.0, 
1990  and  1992 

Informational 

(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS,  Version 
1.1, 1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

MIL-STD- 1472D 
Notice  2,  30  iune 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Gu;  Wines  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Requirements  for  Military  Systems, 
Equipment,  and  Facilities 

M1L-STD-46855B 
26  May  1994 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 

GPC 

DOD 

Department  of  Defence  Intelligence  Information  Systems 
Style  GuHe 

DODIIS  Style 
Guide,  10/91 

Informational 

(Approved) 

IPC 

130 

Ergonomic  Requirements  for  Office  Work  with  VDTs  Part 
10:  Dialogue  principles 

9241-10:1996 

Informational 

(Approved) 
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Sponsor 


Standard 

Type 


Standard 

Reference 


Status 

DoD 

[Lifecycle] 


Standard 
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DODI  8120  mandates  the  DOD  HCI  Style  Guide. 

The  Human-Computer  Interface  (HCI)  Style  Guide  provides  a  common  framework  for  HCI 
design  and  implementation  with  emphasis  on  standard  look  and  feel  for  GUI  based  applications. 
Motif  1.2  is  the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and 
programming  and  data  interfaces.  It  includes  a  style  guide  for  GUI  interfaces. 

3.13.2.1.2  Alternative  specifications.  Several  applicable  consortia  or  de  facto  style  guides  are 
available  for  software  user  interfaces.  These  style  guides  promote  consistency  in  user  interface 
design  across  applications.  However,  conformance  with  one  or  more  the  style  guides  listed  below 
does  not  guarantee  conformance  with  ergonomic  standards  (e.g.,  ISO  9241).  These  style  guides 
include: 

a.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft) 

b.  Object-Oriented  Interface  design:  IBM  Common  User  Access  Guidelines  (IBM) 

c.  Macintosh  Human  Interface  Guidelines  (Apple  Computer) 

d.  SAA  Presentation  Manager  Style  Guide/  Common  User  Access  (CUA)  (IBM) 
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e.  Standard  User  Interface  Style  Guide  for  Compartmented  Mode  Workstations 
(Defense  Intelligence  Agency  (DIA)) 

f.  Compartmented  Mode  Workstation  Labeling:  Source  Code  and  User  Interface 
Guidelines  (DIA) 

g.  Air  Force  Standard  Systems  Center  GUI  Style  Guide,  SSCR  700-10,  Vol  I 

h.  User  Interface  Specifications  for  the  Global  Command  and  Control  System 
(GCCS),  Version  1.0,  draft,  October  1994 

L  Theater  Battle  Management  Style  Guide  (U.S.  Navy) 

j.  Army  Theater  Battle  Management  HCI  Specification 

k.  Navy  JMCIS. 

3.13.2.1J  Standards  deficiencies.  Currently,  conformance  to  parts  12-17  of  the  ISO  9241 
standard  is  on  a  part-by-part  basis.  There  is  concern  that  the  overall  standard  may  thus  fail  to 
address  potential  ergonomic  problems  arising  from  interaction  between  the  user  interface  elements 
covered  by  the  individual  parts. 

There  is  concern  that  ISO/IEC  1 1581  may  contain  overly  rigid  specifications  for  the  set  of  icon 
shapes  that  can  be  used  to  represent  different  user  interface  parts. 

3.13.2.1.4  Portability  caveats.  NIST  FIPS  158-1  (User  Interface  Component  of  the  Applications 
Portability  Profile)  mandates  the  use  of  the  X  Window  protocol,  X  library,  and  X  toolkit 
intrinsics.  IEEE  P1201.2,  when  completed,  is  intended  to  increase  the  level  of  user  interface 
consistency  (and  thus  user  interface  portability)  across  X  Windows-based  environments.  There  are 
potential  conflicts  here. 

DOD  HCI  Style  Guide  is  based  on  (and  intended  to  supersede)  the  Army,  Navy,  Air  Force,  and 
DODIIS  style  guides  cited  in  the  table  above.  The  goal  of  this  effort  is  to  minimize  unnecessary 
user  interface  diversity  across  DOD  systems.  There  are  potential  problems  with  systems  designed 
to  accommodate  different  style  guides. 

MIL-STD-1800  is  an  Air  Force-only  standard  that  duplicates  MIL-STD-1472D  and  is  largely 
ignored  in  Air  Force  acquisitions.  It  has  been  recommended  tint  MIL-STD-1800  be  canceled  and 
any  value  added  material  be  added  to  MIL-STD-1472D. 

3.13.2.1.5  Related  standards.  The  following  standards  are  related  to  user  interface  style  guides: 

a.  ISO  9241-1:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  1: 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
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9241  standard.  A  revised  version  of  ISO  9241-1  is  currently  at  the  CD  level  and 
will  soon  be  released  for  DIS  ballot 

b.  ISO  9241-2:1992,  Ergonomic  requirements  for  office  work  with  VDTs,  part  2: 
Task  Requirements,  present  an  overview  of  factors  that  should  be  considered  when 
designing  tasks  to  be  performed  in  a  specific  computing  environment 

c.  ISO  CD  10075-2,  Ergonomic  principles  related  to  mental  work  load  —  Part  2: 
Design  Principles,  gives  guidance  on  the  design  of  work  systems  in  general,  with 
the  intention  of  providing  optimal  working  conditions  with  respect  to  health  and 
safety,  well-being,  performance,  and  effectiveness. 

d.  MIL-STD-1908  (1992),  Definition  of  Human  Factors  Terms. 

e.  NIST  FIPS  158-1,  User  Interface  Component  of  the  Applications  Portability 
Profile. 

f.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

g.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

h.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

i.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

j.  ITU-T  E.  134  Human  Factors  Aspects  of  Public  Terminals:  Generic  Operating 
Procedures. 

k.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment. 

3.13,2.1.6  Recommendations.  A  style  guide  is  necessary  for  development  of  all  GUIs.  There  are 
no  formal  standards  efforts  in  this  area.  A  style  guide  is  part  of  the  Presentation  Layer  in  NIST 
FIPS  158-1.  Procurements  that  require  software  user  interfaces  to  be  addressed  by  ergonomic 
standards  can  require  conformance  with  standards  for  menu  structures,  command  languages, 
direct  manipulation  dialogs,  forms-based  dialogs,  windowing,  icons,  screen  formatting, 
information  coding,  and  user  guidance. 

It  is  recommended  that  the  practices  of  the  DOD  HC1  Style  Guide,  TAFIM,  Volume  8  be 
followed.  It  provides  a  common  framework  for  HCI  design  and  implementation  with  emphasis  on 
standard  look  and  feel  for  GUI  based  applications.  As  many  aspects  of  standard  GUI  style  are 
application  specific,  application  area  style  guides  should  also  be  used  when  available.  Motif  1 .2  is 
the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and  programming 
and  data  interfaces.  It  includes  a  style  guide  for  GUI  interfaces  and  is  also  recommended. 
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Parts  1  and  2  of  the  ISO  9241  standard  are  informative;  parts  10  and  1 1  are  expected  to  be 
informative  on  completion.  Parts  12-17  are  expected  to  be  normative  on  completion. 
Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product.  The  ISO/1EC  1 1581  standard  is  expected  to  be  normative 
on  completion. 
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3.13.2.2  Visualization.  (This  BSA  appears  in  part  3,  User  Interface,  and  f.  1 13,  Human 
Factors.)  Visualization  is  the  method  of  displaying  data  in  a  graphical  mannt.  to  aid  in 
recognition  of  patterns  and  trends  in  data  and  to  give  the  viewer  a  depiction  of  a  physical  system 
that  has  been  modeled  by  data  points  (e.g.,  finite  element  analysis  (FEA)  and  computational  fluid 
dynamics  (CFD)).  Another  technique  is  the  visualization  user  interface  (VU1),  a  GUI  that 
interprets  text  and  numbers  as  pictures  to  show  their  relative  scales  and  other  relationships.  A 
VUI  remodels  data  so  that  text  and  numbers  are  hidden  behind  a  picture  expressing  their  complex 
relationships.  Engineering  visualization  is  a  term  freely  applied  to  almost  any  intersection  where 
the  engineering  process  meets  imag  Teation  technologies. 

3.13JJ.1  Standards.  Table  3.13-'-  .  tsents  visualization  standards. 


TABLE  3.13-5  Visualization  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPC 

ANSl/SAE 

Aerodynamic  Row  Vi  wall  rati  on  Tudinique*  and 
Procedure* 

HSJ  3566-  1986 

Informational  * 
(Approved)  | 

3.13.2 22  Alternative  specifications.  There  are  no  alternative  specifications  available,  but 
extensive  academic  research  on  this  topic  is  taking  place,  particularly  in  the  University  of 
Maryland's  Human-computer  Interaction  Laboratory  and  the  Software  Psychology  Society. 
Topics  include  using  treemaps  for  visualizing  hierarchical  information,  using  statistical  distortion 
to  promote  the  detection  c,  outlying  data,  and  use  of  color  coding  as  a  visualization  aid. 

3.13.2.2  J  Standards  deficiencies.  Deficiencies  in  the  existing  standard  are  unknown. 

3.13.2.2.4  Portability  caveats.  Portability  problems  with  the  existing  standard  are  unknown. 

3.13.2.2.5  Related  standards.  The  following  standards  are  related  to  visualization  standards: 

a.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems 

b.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems 

c.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms 

d.  MIL-HDBK-761A  (1989)  Human  Engineering  Guidelines  for  Management 
Information  Systems 

e.  DOD-KDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

3.13.2.2.6  Recommendations.  There  are  no  recommendations  for  visualization  itself,  but  it  does 
require  the  use  of  pow  er  graphics  generation  if  a  dynamic  system  will  be  shown,  rather  than  a 
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series  of  static  views.  Other  requirements  can  include  a  high  degree  of  mathematical  precision  and 
single-pixel  accuracy  in  rendering. 


April  7,  1997 


3.13-17 


Version  3. 1 


Information  Technology  Standards  Guidance 


Human  Factors  Services 


3.13.23  Color  use.  (This  BSA  appears  in  part  3,  User  Interface,  and  part  13,  Human  Factors.) 
The  use  of  color  is  a  vital  part  of  communication  with  the  user  of  computer  applications. 
Computer  representation  of  color  is  done  through  the  use  of  the  Red,  Green,  Blue  (RGB)  color 
separation  method  which  must  be  used  to  approximate  color  definitions  used  in  graphic 
technologies. 

3.13.2.3.1  Standards.  Table  3.13-6  presents  standards  for  color  use. 


TABLE  3.13-6  Color  use  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  lute,  face  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

IPC 

cm 

Recommendations  oo  Uniform  Color  Spaces,  Color- 
Differeooe  Equations,  and  Psyduometric  Color  Terms 

CIE  Pub.  15,  Suppl. 
2(1986) 

Informational 

(Approved) 

IPC 

NATO 

Aircraft  Electronic  Colour  Display  Systems 

STANAG  3940 
(1991) 

Informational 

(Approved) 

|  j|||P|I|| 
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DODI  8120  mandates  use  of  the  DOD  HCI  Style  Guide.  The  DOD  HC1  Style  Guide  addresses 
use  of  color  and  the  meaning  of  color  in  section  4.3, 

3.13.2 3.2  Alternative  specifications.  Alternative  specifications  include  any  user  interface  style 
guide  that  addresses  the  use  and  meaning  of  color. 

3.13.2.3 3  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards 
assumes  identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons 
across  viewing  environments,  although  models  are  being  worked  on. 

3.13.2.3.4  Portability  caveats.  Translation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  best.  There  are  three  different  color  definitions 
from  the  CIE.  The,  are  ClEXYZ,  CIELAB,  and  CIELUV.  These  standards  have  existed  for  a 
long  time  and  are  seen  as  the  common  basis  for  any  future  unifying  definitions. 

One  problem  with  the  use  of  color  is  color  blindness.  To  accommodate  the  color  blind,  if  color  is 
used  to  convey  important  information,  then  a  second  method  should  also  be  used  (such  as 
brightness  of  the  color). 

3.13.2.3.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
the  use  of  color: 

a.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems 
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b.  MIL-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems 

c.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms 

d.  MIL-HDBK-761A  (1989)  Human  Engineering  Guidelines  for  Management  Info. 
Systems 

e.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

'  ' "  3.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
U.  -  u  applicable.  The  DOD  HCI  Style  Guide  is  recommended,  particularly  section  4.3  which 
addresses  the  use  and  meaning  of  color. 
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3.132.4  Color  definition.  (This  BSA  appears  in  part  5,  Data  Interchange,  part  12,  Multimedia, 
and  part  13,  Human  Factors.)  Color  definition  deals  with  establishing  a  ref'.rence  base  for 
identifying  colors  to  aid  in  the  matching  and  exchange  of  color.  Color  definition  standards  apply 
to  defining  color  in  general,  and  not  only  to  color  definition  for  informatir  technology  systems. 

3.13.2.4.1  Standards.  Table  3. 13-7  presents  standards  for  color  definition. 


TABLE  3.13-7  Color  definition  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Litecycle) 

NPC 

ASTM 

Standard  Test  Method  for  Computing  the  Colon  of  Objects 
by  Using  the  CIE  System 

E308 (1990) 

Informational 

(Approved) 

NPC 

EIA 

1976  CIE-UCS  Chromatirity  Diagram  with  Color 
Botmdaries 

TEB26  (1988) 

Informational 

(Approved) 

IPC 

ISO 

CIE  Standard  Colorimetric  Dluminants 

CIE  1  '  16(1991) 

Informational 

(Approved) 

IPC 

ISO 

CIE  Standard  Colorimetric  Observers 

CIE  10527(1991) 

Informational 

(Approved) 

IPC 

CIE 

Recommendations  on  Uniform  Color  Spaces,  Color- 
Difference  Equations,  and  Psyduumetric  Color  Terms 

CIE  Pul  15,Suppl. 
2(1986) 

Informational 

(Approved) 

NPC 

NPESA 

IT8.7"  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Aits  Prepress  Definition  of  Default  RGB  Data  for 
Use  in  the  Graphic  Arts  Industry 

'T8.7/4 

Informational 

(Approved) 

m 

SMPTE/EIA/VE 

S  A/ISO 

Unreferenced  24-hit  ROB 

Technical  Reports 

Informational 

(Approved) 
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The  CIE  (International  Commission  on  Illumination)  is  the  principal  inti  rnal  standards 
writing  body  for  agreements  for  color,  vision,  and  illumination.  Under  t  '  .  four  bodies  work  on 
color-related  standards.  ANSI  X3  works  on  office  document  automation  >  information  systems. 
ANSI  IT8/CGATS  is  concerned  with  graphic  arts.  ASTM  deals  with  coloi  metrology  and 
standard  practices,  and  SMPTE  handles  standards  for  color  television  and  color  monitors. 

ANSI's  Committee  for  Graphic  Arts  Technology  Standards  (CGATS)  has  eight  subcommittees 
working  on  topics  such  as  materials  handling,  process  control,  and  color  data  definition.  NPESA 
is  the  National  Printing  Equipment  and  Supply  Association. 

3.13.2.4.2  Alternative  specifications.  Die  following  alternative  specifications  are  also  available: 
a.  Pantone  Matching  S>  ’em 
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b.  ROB  (Red,  Green,  Blue)  -  the  method  directly  used  by  color  video  display 
terminals 

c.  CMYK  (Cyan,  Magenta,  Yellow,  Black)  -  used  in  four  color  printing 

d.  HSV  (Hue,  Saturation,  V.) 

e.  HSL  (Hue,  Saturation,  Luminescence) 

f.  HVC 

g.  SWOP  (Specifications  for  Web  Offset  Publications) 

h.  HSB  (Hue,  Saturation,  Brightness) 

i.  TIFF  (Tag  Image  File  Format) 

3. 13.2.4.3  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards 
assumes  identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons 
across  viewing  environments,  although  models  are  being  worked  on.  Strict  adherence  to  correct 
presentation  and  output  standards  will  require  color  calibration  equipment 

3.13.2.4.4  Portability  caveats.  Translation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  best  There  are  three  different  color  definitions 
from  the  CIE.  They  are  the  CIEXYZ  tristimulus  values,  and  the  CIELAB  and  CDELUV  color 
spaces.  These  standards  have  existed  for  a  long  time  and  are  seen  as  the  common  basis  for  any 
future  unifying  definitions.  There  are  also  the  problems  of  color  matching.  For  example,  of  1012 
Pantone  colors  for  coated  paper,  70  cannot  be  reproduced  in  the  CMYK  definition.  CIEXYZ  is 
useful  in  comparing  colors  under  identical  viewing  conditions.  CIEXYZ  has  a  rigorous  definition 
and  by  itself  does  not  necessarily  constitute  a  complete  color  specification.  CIEXYZ  is  a 
standardized  set  of  primaries  which  are  not  physically  realizable  but  can  match  all  possible  colors 
with  entirely  positive  tristimulus  values.  A  new  form  of  color  definition  is  emerging,  known  as 
high-fidelity  color.  The  idea  behind  high-fidelity  color  is  the  use  of  five  to  seven  different  colors  in 
the  printing  process  to  widen  the  range  of  colors  that  can  be  printed.  Two  such  models  that  have 
appeared  are  the  Kupper  set  which  increases  the  number  of  printed  colors  in  the  blue  region  by 
80%,  and  the  VSF  model  which  provides  better  performance  in  deep  red  and  green  colors.  These 
processes  are  very  non-standard  and  should  be  avoided  at  present. 

Common  systems  typically  do  not  support  colorimetric  calibration.  * 

3.13.2.45  Related  standards.  The  following  types  of  standards  are  related  to  standards  for  the 
definition  of  color: 

a.  color  matching  standards 

b.  color  data  exchange  standards 
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c.  color  use  standards 

d.  style  guide  standards 

3.13.2.4.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  Maintain  original  copies  of  source  material  so  that  revisions  can  be  produced 
for  next  generation  systems  that  will  allow  the  inclusion  of  calibration  information. 
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3.13 2S  Color  data  interchange.  (This  BSA  appears  in  part  S,  Data  Interchange,  and  part  13, 
Human  Factors.)  This  BSA  deals  with  the  specific  problems  of  interchanging  data  about  color  in 
computer  graphics. 


3.13.2 .5.1  Standards.  Table  3.13-8  presents  standards  for  color  data  interchange. 


TABLE  3.13-8  Color  data  interchange  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Graphic  Technology  -  Prapre**  Digital  Datt  Exchange  • 
Colour  Picture  Data  on  Magnetic  Tape  (ANSI  IT8.1-I988) 

10755:1992 

Informational 

(Approved) 

IPC 

ISO 

Graphic  Technology  -  Prepre**  Digital  Data  Exchange  - 
Colour  Line  Aft  Data  on  Magnetic  Tape 

10756:1994 

Informational 

(Approved) 

IPC 

ISO 

Graphic  Technology  ■  Prepreai  DigiUl  Data  Exchange  • 
Online  Tratufer  from  Electronic  Piepreu  Syilcmi  to 
Colour  Hardcopy  Device* 

10758:1994 

Informational 

(Approved) 

NPC 

NPESA 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Art*  Prepre**  Definition  of  Default  RGB  Data  for 
U*e  in  the  Graphic  Art*  lodu* try 

IT8.7/4 

Informational 

(Approved) 

""  MU' 

HMc 

1 

Bllli 

{Draft) 

The  Generic  Architecture  for  Colour  Data  Interchange  (GACDI)  standard  is  a  color  architecture 
standard  that  will  provide  a  consistent  color  framework  across  document-related  standards.  This 
standard  will  enable  users  to  interchange  color  information  in  an  open  systems  environment 
through  the  use  of  color  data  and  transform  representations. 

3.13.2.5.2  Alternative  specifications.  No  alternative  specifications  are  available. 

3.13.2.5.3  Standards  deficiencies.  There  are  no  standards  directly  addressing  comparison  across 
viewing  environments,  although  models  are  being  worked  on. 

3.13.2.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.13.2.5.5  Related  standards.  Data  interchange  standards  are  related  to  standards  for  color  data 
exchange. 

3.13.2.5.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable. 
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3.13.2.6  Color  matching.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  13,  Human 
Factors.)  This  BSA  deals  with  the  problem  of  matching  displayed  and  printed  colors  in  computer 
systems. 

3.13.2.6.1  Standards.  Table  3.13-9  presents  standards  for  color  matching. 


TABLE  3.13-9  Color  matching  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

tPC 

ISO 

Graphic  Technology  •  Prepredi  Digital  Data  Exchange  - 
Online  Tnuufer  from  Electronic  Pnpreai  Syatemi  to 
Colour  Hardcopy  Device* 

10758:1994 

Informational 

(Approved) 

NPC 

ASTM 

Standard  Teat  Method  for  Computing  the  Colon  of  Object! 
by  Using  the  CE  System 

E308(1990) 

Informational 

(Approved) 

IPC 

CIE 

Recommendation!  on  Uniform  Color  Space*,  Color- 
Difference  Equation*,  and  Piychroroetric  Color  Term* 

CIE  Pub.  15.Suppl. 
2(1986) 

Informational 

(Approved) 

NPC 

NPESA 

IT8.7/3  (1993) 

Informational 

(Approved) 

NPC 

NPESA 

Graphic  Art*  Prepre**  Definition  of  Default  RGB  Data  for 
U*e  in  the  Graphic  Arts  Induttiy 

IT8.7/4 

Informational 

(Approved) 

CPC 

ICC 

ICC  Profile  Format 

ICC  Profile  Format 
ver.  3. 1994 

Informational 

(Approved) 

/■  J#5fe 

wmsm 

The  ICC  was  formed  in  March,  1994,  by  Apple,  Adobe,  Silicon  Graphics,  Taligent,  Agfa,  Kodak, 
Microsoft,  and  Sun  for  the  purpose  of  defining  profiles  for  color  handling.  The  ICC  Profile  format 
has  no  preferred  color  space,  and  provides  for  more  than  four  input  colors. 

ColorSync  Profile  Consortium  has  adopted  the  CGATS.5  specification  as  its  definition  of 
colorimetry  and  color  measurement 

The  Open  System  Color  Association  (OSCA)  has  taken  on  the  role  of  providing  industry  with  a 
centralized,  stable,  reliable,  and  common  source  of  certified  color-calibration  data.  OSCA  consists 
of  Agfa,  DuPont,  Fujifilm,  Kodak,  Radius,  3M,  and  24  other  non-founding  member  companies. 
OSCA's  work  is  in  harmony  with  the  ICC  Profile  format 

3.13.2.6.2  Alternative  specifications.  The  following  alternative  specifications  are  also  available: 

a.  Pantone  Matching  System  (PMS) 

b.  RGB  (Red,  Green,  Blue)  -  the  method  directly  used  by  color  video  display 
terminals 

c.  CMYK  (Cyan,  Magenta,  Yellow,  Black)  -  used  in  four  color  printing 
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d.  Apple  ColorSync  2.0  (supports  ICC  and  CMYK) 

e.  Kodak  Precision  Color  Management  System  (CMS) 

f.  Electronics  for  Imaging  (EFI)  Inc.,  EFIColor 

g.  Hewlett-Packard  ColorSmart 

h.  Microsoft  Independent  Color  Matching  (ICM)  in  future  versions  of  WindowsNT 
and  Windows  95.  (accepts  ICC  Profile  Format). 

i.  Pantone  Open  Color  Environment  (POCE)  (overshadowed  by  CMS  and 
ColorSync) 

j.  Pantone  ColorDrive  (to  standardize  color  palettes) 

k.  Trumatch  SwatchPrinter 

L  Tektronix  TekColor 

m.  Agfa-Gevaert  FotoFlow 

3.13.2.6.3  Standards  deficiencies.  Comparison  of  color  defined  by  the  existing  standards 
assumes  identical  viewing  conditions.  There  are  no  standards  directly  addressing  comparisons 
across  viewing  environments,  although  models  are  being  worked  on.  The  issue  of  where  and  how 
to  correct  color  remains  unresolved. 

3.13.2.6.4  Portability  caveats.  Translation  of  color  from  one  color  definition  system  to  another 
can  be  difficult  and  is  only  an  approximation  at  best.  There  are  three  different  color  definitions 
from  the  CIE.  They  are  CDEXYZ,  CIELAB,  and  CIELUV.  These  standards  have  existed  for  a 
long  time  and  are  seen  as  the  common  basis  for  any  future  unifying  definitions. 

Because  of  their  display  orientation,  all  standards  that  are  defining  computer  generated  graphics 
color,  use  RGB  models.  Most  programmers  assume  that  the  RGB  values  they  are  using  are  linear 
with  display  intensity  and  that  may  be  approximately  true  depending  on  the  response  of  the 
graphics  system.  The  actual  colors  produced  vary  according  to  the  graphics  system  used. 

3.13.2.6.5  Related  standards.  Color  definition  standards  are  related  to  human  factors  standards 
for  color  matching. 

3.13.2.6.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable, 


April  7,  1997 


3.13-25 


Version  3. 1 


3.13.2.7  Customization  to  local  norms.  (This  BSA  appears  in  part  3,  User  Interface,  part  13, 
Human  Factors,  and  part  14,  Internationalization.)  Customization  to  local  norms  involves 
modification  of  the  key  mapping  to  accommodate  the  local  language  and  display  of  data  in  the 
commonly-used  format  (e.g.,  numbers,  dates,  time). 

3. 13.2.7.1  Standards.  Table  3.13-10  presents  standards  for  customization  to  local  norms. 


TABLE  3.13-10  Customization  to  local  norms  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human -Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

X/Opw 

Internationalisation  Guide,  version  2 

G304  (7/93) 

Informational 

(Approved) 

CPC 

X/Open 

Locate  Registry  Procedures 

G303  (1993) 

Informational 

(Approved) 

CPC 

QSF 

Motif  1.2  (consistent  with  X/Opeo'i  NLS  specifications  & 
si  so  double-byte  character  sets) 

Motif  1.2 

Informational 

(Approved) 

CPC 

MTTX 

Consortium 

X  Window  System  (X  font  manager-  includes  double-byte 
chancier  sets) 

X11R5 

Informational 

(Approved) 

NPC 

ANSl/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Diq>Eay  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

GPC 

DOD 

Military  Standard  Keyboard  Anangementi 

MIL-STD-1280, 
Notice  1,  1969 

Informational 

(Approved) 

GPC 

DcD 

User/Computer  Interface 

MIL-STD-1801  29 
May  1987 

Informational 

(Aprmved) 

GPC 

DOD 

Human  Engineering  Performance  Requirements  for 
Systems 

MIL-STD-1800A 

10  Oct.  1990 

Informational 

(Approved) 

GPC 

DOD 

DOD  Handbook,  Human  Engineering  Guidelines  for 
Management  Information  Systems 

MIL-HDBK-761A 
30  Sep.  1989 

Informational 

(Approved) 

GPC 

DOD 

Guidelines  for  Designing  User  Interface  Software 

ESD-TR-86-278 

Informational 

(Approved) 

GPC 

DOD 

Department  of  Defense  Intelligence  Information  Systems 
Style:  Guide 

DOD1IS  Style 

Guide,  10/91 

Informational 

(Afproved) 

GPC 

DOD 

Air  Force  Intelligence  Dais  Handling  System  (IDHS)  Style 
Guide 

IDHS  Style  Guide 
1990 

2  b 

GPC 

DOD 

Human  Factors  Guidelines  for  the  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier-Machine 
Interface 

ATCCS  Guidelines 
v.1.0  and  v.2.0. 
1990  and  1992 

Informational 

(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS,  Version 
1.1,1992 

Informational 

(Approved! 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  and  Facilities 

MIL-STD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Guidelines  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

Informational 

(Approved) 

CPC 

X/Open 

Distributed  Internationalisation  Services 

S213  (11/92) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

crc 

X/Open 

CPC 

X/Open 

CPC 

X/Open 

CPC 

X/Open 

CPC 

X/Open 

NPC 

ANSI/S  AE 

GPC 

DOD 

CPC 

X/Open 

CPC 

X/Open 

CPC 

X/Open 

CPC 

OSF 

Standard 


In  twnjfccoab  ration  of  Internetworking  Specification! 


File  Sytteai  Safe  UCS  Tramfonnabon  Fonnat  (FSS-UTF) 


Syrtem  Interface  tod  Header*,  luue  3 


Supplementary  Definition*,  luue  3 


Universal  Multiple-Octet  Coded  Qurarter  Set  Coexutenoe 
and  Migration 


Human  Interface  Deeign  Methodology  for  Integrated 
Display  Symbology 


Single  Unix  Specification  (Spec  1 170),  Syitem  Interface 
Definition!,  luue  4,  Veraion  2  (part  of  XPG4) 


Single  Unix  Specification  (Spec  1 170),  Syrtem  Interfaces 
and  Header*,  luue  4,  Venion  2,  (Part  of  XP04) 


Locale  Registry  Procedures,  Version  2 


Motif 


Standard 

Reference 

Status 

DoD 

(Lifecycle) 

S302  (4*3) 

Eafonudootl 

(Approved) 

P3 16  (1993) 

Informational 

(Approved) 

C212  (3/92) 

Informational 

(Approved) 

C213  (3/92) 

Informational 

(Approved) 

E401  (3/94) 

Infoimational 

(Approved) 

ARP  4 155  (1990) 

Infoimational 

(Approved) 

MIL-STD-468J5B 
26  May  1994 

Informational 

(Approved) 

C434  (9/94) 

Infoimational 

(Approved) 

C435  (9/94) 

Infoimational 

(Approved) 

0502  (5/95) 

Infoimational 

(Approved) 

Motif  2.0 

Infoimational 

(Approved) 

DODI  8120  mandates  use  of  the  DOD  HCI  Style  Guide 

Motif  1.2  is  the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and 
programming  and  data  interfaces.  XI 1R5  is  the  current  release  of  Version  1 1  of  the  X  Windows 
standard. 

3.13.2.7.2  Alternative  specifications.  Several  applicable  consortia  or  de  facto  style  guides  are 
available  for  internationalization.  However,  conformance  with  one  or  more  the  style  guides  listed 
below  does  not  guarantee  conformance  with  ergonomic  standards: 

a.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft) 
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b.  Object-Oriented  Interface  design:  IBM  Common  User  Access  Guidelines  (IBM) 

c.  Macintosh  Human  Interface  Guidelines  (Apple  Computer). 

3.13.2.7.3  Standards  deficiencies.  Currently,  conformance  to  parts  12-17  of  the  ISO  9241 
standard  is  on  a  part-by-part  basis.  There  is  concern  that  the  overall  standard  may  thus  fail  to 
address  potential  ergonomic  problems  arising  from  interactions  between  the  user  interface 
elements  covered  by  the  individual  parts. 

j.13 .2.7.4  Portability  caveats.  Although  Motif  supports  the  X/Open  Native  Language  System,  it 
also  supports  a  number  of  its  own  internationalization  extensions  which  makes  it  incompatible 
with  some  legacy  specifications  (e.g.,  OpenLook). 

NIST  FIPS  158-1  (User  Interface  Component  of  the  Applications  Portability  Profile)  mandates 
the  use  of  the  X  Window  protocol,  X  library,  and  X  toolkit  intrinsics.  IEEE  P1201.2,  when 
completed,  is  intended  to  increase  the  level  of  user  interface  consistency  (and  thus  user  interface 
portability)  across  X  Windows-based  environments.  There  are  potential  conflicts  here. 

The  DOD  HCI  Style  Guide  is  based  on  (and  intended  to  supersede)  the  Army,  Navy,  Air  Force, 
and  DODIIS  style  guides  cited  in  the  table  above.  The  goal  of  this  effort  is  to  minimize 
unnecessary  user  interface  diversity  across  DOD  systems.  There  are  potential  problems  with 
systems  designed  to  accommodate  different  style  guides. 

3.13.2.7.5  Related  standards.  The  following  standards  are  related  to  cultural  convention 
services: 

a.  X/Open  Internationalisation  Locale:  L001  (1994):  ja_JP  -  Japanese  for  Japan. 

b.  X/Open  Internationalisation  Locale:  L002  (1994):  da_DK  -  Danish  for  Denmark. 

c.  X/Open  Internationalisation  Locale:  L003  (1994):  de_AT  -  German  for  Austria. 

d.  X/Open  Internationalisation  Locale:  L004  (1994):  en_DK  -  English  for  Denmark. 

e.  X/Open  Internationalisation  Locale:  L005  (1994):  fo_FO  -  Faroese  for  the  Faroes. 

f.  X/Open  Internationalisation  Locale:  L006  (1994)  is_IS  -  Icelandic  for  Iceland. 

g.  X/Open  Internationalisation  Locale:  L007  (1994)  kl_GL  -  Greenlandic  for 

Greenland. 

h.  X/Open  Internationalisation  Locale:  L008  (1994)  lt_LT  -  Lithuanian  for  Lithuania. 

i.  X/Open  Internationalisation  Locale:  L009  (1994):  lv_LV  -  Latvian  for  Latvia. 
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j.  X/Open  Internationalisation  Locale:  L010  (1994):  de_CH  -  German  for 
Switzerland 

k.  X/Open  Internationalisation  Locale:  L01 1  (1994):  de_DE  -  German  for  Germany. 

L  X/Open  Internationalisation  Locale:  L012  (1994):  en_GB  -  English  for  Great 

Britain. 

m.  X/Open  Internationalisation  Locale:  L013  (1994):  en_IE  -  English  for  Ireland. 

n.  X/Open  Internationalisation  Locale:  L014  (1994):  en_US  -  English  for  the  U.S.A. 

o.  X/Open  Internationalisation  Locale:  L015  (1994):  hu_HU  -  Hungarian  for 

Hungary. 

p.  X/Open  Internationalisation  Locale:  L016  (1994):  it_IT  -  Italian  for  Italy. 

q.  X/Open  Internationalisation  Locale:  L017  (1994):  nl_NL  -  Dutch  for  the 

Netherlands. 

r.  X/Open  Internationalisation  Locale:  L018  (1994):  pl_PL  -  Polish  for  Poland. 

s.  X/Open  Internationalisation  Locale:  L019  (1994):  pt_PT  -  Portuguese  for 

Portugal. 

t.  X/Open  Internationalisation  Locale:  L020  (1994):  ro_RO  -  Romanian  for 
Romania 

u.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

v.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms. 

w.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

3.13.2.7.6  Recommendations.  Procurements  that  require  software  user  interfaces  to  be 
addressed  by  ergonomic  standards  can  require  conformance  with  standards  for  menu  structures, 
command  languages,  direct  manipulation  dialogs,  forms-based  dialogs,  windowing,  icons,  screen 
formatting,  information  coding,  and  user  guidance. 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative:  parts  10  and  1 1  are  expected  to  be 
informative  on  completion.  Part  3  of  the  ISO  9241  standard  is  normative;  parts  2-9  and  12-17  are 
expected  to  be  normative  on  completion.  Conformance  with  the  overall  ISO  9241  standard  is 
based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 
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Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  DOD  HCI  Style  Guide  is  recommended  for  customization  to  local  norms. 


April  7,  1997 


3.13-30 


Version  3. 1 


Human  Factors  Services 


Information  Technology  Standards  fluiriance 

3.13  3  Human  factors  for  computer  environments.  This  Mid-Level  Service  Area  addresses  (he 
environment  as  it  affects  both  the  user  and  the  computer. 

3.133.1  Human  factors  for  the  physical  environment  (This  BSA  appears  in  both  part  3,  User 
Interface,  and  part  13,  Human  Factors.)  Procurements  that  require  computing  environments  to  be 
addressed  by  ergonomic  standards  can  require  conformance  with  standards  for  illuminance,  glare, 
acoustic  noise,  the  thermal  environment,  electromagnetic  emissions,  computer  workspace  design 
and  furniture  design. 

The  effects  of  low-level  non-ionized  radiation,  particularly  from  CRTs,  on  humans  have  been  a 
controversial  topic.  Over  the  years  there  have  been  articles  advising  pregnant  women  who  have  a 
prior  history  of  miscarriage  to  stay  away  from  working  in  computer  areas.  During  the  cold  war, 
the  Soviets  were  suspected  of  secretly  bombarding  foreigners  with  non-ionized  radiation  to  study 
long  term  effects.  People  who  live  near  high  voltage  power  lines  and  have  developed  cancer  are 
suspected  victims  of  electromagnetic  radiation.  While  there  are  no  hard  theories  to  describe  the 
relationship  between  health  problems  and  this  kind  of  radiation,  let  alone  a  standard  established. 
Some  VDT  vendors  have  made  claims  regarding  the  emissions  of  their  products  and  there  are 
aftermarket  shielus  available  that  may  provide  some  protection  against  this  form  of  radiation. 

Laser  printers  are  said  to  emit  ozone  during  the  printing  process.  In  an  enclosed  area,  high  levels 
of  ozone  can  be  unhealthy  or  even  toxic.  This  issue  is  still  unclear.  It  remains  to  be  seen  how 
much  ozone  is  emitted  and  what  concentrations  are  hazardous. 

3.133.1.1  Standards.  Table  3.13-1 1  presents  human  factors  standards  for  the  physical 
environment 


TABLE  3.13-11  Human  factors  for  the  physical  environment  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human-Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8. 
Version  3.0: 1996 

Mandated 

(Approved) 

CPC 

OSF 

Motif  Style  Guide 

Motif  SG  Rev. 
1.2:1992 

Mandated 

(Approved) 

The  Windows  Interface:  An  Application  Design  Guide, 
Microsoft  Press,  1992 

API  Design  Guide 

Mandated 

(Approved) 

NPC 

ANSI/HFS 

American  National  Standard  for  Human  Factors 
Engineering  of  Visual  Display  Terminal  Workstations 

100-1988 

Informational 

(Approved) 

CPC 

DOD 

Noise  Limits  for  Military  Material 

MIL-STD-U74C 
of  8  March  1991 

Informational  1 
(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Sy4ems, 
Equipment  and  Facilities 

MIL-STD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Physical  Ear  Noise  Attenuation  Testing 

MIL-STD-912  of 

1 1  December  1990 

Informational 

(Approved) 

IPC 

ISO 

Ergonomic  Principles  Related  to  Mental  Work  Load  - 
General  Terms  and  Definitions 

10075:1991 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO 

IPC 

ISO 

NPC 

EIA 

CPC 

NSC 

CPC 

NSC 

CPC 

NSC 

CPC 

NSC 

IPC 

ECMA 

IPC 

ECMA 

IPC 

ECMA 

IPC 

ECMA 

IPC 

ECMA 

IPC 

ECMA 

Standard 


PrindplM  of  Visual  Ergooooic*  -  Lighting  of  Indoor  Woi 
System* 


Standard 

Reference 


Expression  of  UMn'  Requirements  Put  3:  Acoustical 


Coasidentioru  Used  in  Eatabtiduag  the  X-Radiation 
Ratings  of  Monochrome  and  Color  Direct-View  Television 
Picture  and  Data  Dinky  Tubes 


Ergooomic*  in  Computerized  Office* 


Guide  to  Working  Safely  with  Computer*  -  Mutual  (relate* 
toVDTs) 


Guide  to  Working  Safely  with  Computer* 


Working  Safely  with  Your  Computer 


Ergonomic*  -  Recommendation*  for  VDU  (Visual  Display 
UniU)  Work  Placet 


Application  of  Human  Engineering  to  Advanced  Aircrew 
System* 


Measurement  of  Airborne  Noise  Emitted  by  Computer  and 
Business  Equipment 


Measurement  of  High  Frequency  Noise  Emitted  by 
Computer  and  Business  Equipment 


Declared  Norse  Emission  Values  of  Computer  and 
Business  Equipment 


Determination  of  Sound  Power  Levels  of  Computer  and 
Business  Equipment  Using  Sound  Intensity  Measurements; 
Scanning  Method  in  Controlled  Rooms 


TCP  194,  Amd  1 
1987,  Amd  ”,  1988 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informafic'H 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


Informational 

(Approved) 


DODI  8120  mandates  use  of  the  DOD  HCI  Style  Guide. 

3.13.3.1.2  Alternative  specifications.  MPR 11  1990:8  (Test  Methods  for  Visual  Display  Units, 
Section  2.0. 1 )  is  a  Swedish  Hr—  'ment  containing  recommended  values  for  electronic  emissions 
from  visual  display  units.  Whue  not  an  ISO  standard,  it  serves  as  a  de  facto  electromagnetic 
emissions  standard  for  displays  in  most  other  countries.  Many  vendors  of  monitors  claim 
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compliance  with  this  or  a  similar  specification.  After-market  radiation  and  glare  shields  are  also 
available. 

3.133.13  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.133.1.4  Portability  caveats.  MIL-STD-1474C's  criteria  are  more  stringent  than  those  of  the 
Occupational  Safety  and  Health  Administration  and  also  covers  additional  topics  such  as 
nondetectability.  This  standard  may  be  incorporated  into  the  next  revision  of  MIL-STD-1472, 
eliminating  the  need  to  retain  MIL-STD-1474C. 

3.133.1.5  Related  standards.  The  following  standards  are  related  to  human  factors  standards  for 
computer  environments: 

a.  ISO  9241-1:1992,  Ergonomic  Requirements  for  Office  Work  with  VDTs,  part  1: 
Introduction,  presents  an  overview  of  the  content  and  usage  of  the  multipart  ISO 
9241  standard.  A  revised  version  of  ISO  9241-1  is  at  the  CD  level  and  will  soon  be 
released  for  DIS  ballot 

b.  ANS1/ASHRAE  55,  Thermal  Environmental  Conditions  for  Human  Occupancy, 
1992. 

c.  ANSI  S12.10-1985,  Method  for  Measurement  and  Designation  of  Noise  Emitted 
by  Computer  and  Business  Equipment 

d.  ANSI  SI. 13-1971,  Methods  for  the  Measurement  of  Sound  Pressure  Levels. 

c.  ANSI  X5. 1  - 1 985,  Tests  for  General  Office  Chairs. 

f.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

g.  M1L-STD-1800A  (1990)  Human  Engineering  Performance  Requirements  for 
Systems. 

h.  MIL-HDBK-759B(2)  (1993)  Human  Factors  Engineering  Design  for  Army 
Materiel.  (Draft  759C  is  complete.) 

i.  M1L-HDB  K-76 1 A  ( 1 989)  Human  Engineering  Guidelines  for  Management 
Information  Systems. 

j.  DOD-HDBK-763  (1987)  Human  Engineering  Procedures  Guide. 

k.  DOD-HDBK-743A  (1991)  Anthropometry  of  U.S.  Military  Personnel. 

l.  MIL-STD-740-1  (1986)  Airborne  Sound  Measurements  and  Acceptance  Criteria 
of  Shipboard  Equipment 
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m.  MIL-STD-740-2  (1986)  Structurcbome  Vibratory  Acceleration  Measurements 
Acceptance  Criteria  of  Shipboard  Equipment 

n.  MIL-STD- 1 294A  (1985)  Acoustical  Noise  Limits  in  Helicopters. 

o.  An  ISO  work  item  for  a  standard  on  "Human-Centered  design"  has  been  approved, 
but  no  working  draft  has  yet  been  released  for  comment 

3.13 3.1.6  Recommendations.  The  approved  standards  in  this  section  are  recommended  where 
they  are  applicable.  Parts  2-9  and  12-17  are  expected  to  be  normative  on  completion. 
Conformance  with  the  overall  ISO  9241  standard  is  based  on  conformance  with  all  normative 
parts  that  apply  to  a  particular  product. 

The  DOD  HCI  Style  Guide  is  recommended  particularly  for  section  3,  which  covers  hardware. 
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3.14  Internationalization.  Internationalization  i$  the  adaptation  of  a  computer  system's  interface 
to  present  data  according  to  local  conventions  and  to  use  character  sets  that  support  the  local 
language. 

NOTE:  Throughout  Pan  14,  all  tables  shall  have  abbreviations  listed  under  the  column  (Standard 
Type)  as  follows: 

a.  National  Public  Consensus  =  NPC 

b.  International  Public  Consensus  =  IPC 

c.  Government  Public  Consensus  =  GPC 

d.  Consortia  Public  Consensus  =  CPC 

e.  Corporate  Private  Non-Consensus  =  CPN-C 

3.14.1  Character  set  and  data  representation.  A  character  set  is  a  subset  of  all  letters  in 
different  alphabets,  numbers,  punctuation  marks,  mathematical  symbols,  and  other  characters  used 
by  computers.  These  services  include  the  capability  to  input,  store,  manipulate,  retrieve, 
communicate,  and  present  data  independent  of  the  coding  scheme  used. 

3.14.1.1  Coded  character  sets.  (This  BSA  appears  in  both  part  5,  Data  Interchange,  and  part 
14,  Internationalization.)  A  character  set  is  a  subset  of  all  letters  in  different  alphabets,  numbers, 
punctuation  marks,  mathematical  symbols,  and  other  characters  used  by  computers.  These 
services  include  the  capability  to  input,  store,  manipulate,  retrieve,  communicate,  and  present  data 
independent  of  the  coding  scheme  used. 

3.14.1.1.1  Standards.  Table  3.  14-1  presents  standards  for  coded  character  sets. 


TABLE  3.14-1  Coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

Coded  Graphic  Character  Set  for  Text  Communication  - 
Latin  Alphabet  Second  Edition  (replaces  6937  pLl  &  pt  2) 

6937:1994 

Adopted 

(Approved) 

IPC 

1SO/IEC 

Coded  Graphic  Character  Set  for  Use  in  the  Preparation  of 
Documents  used  in  Electrotechnology  and  for  Information 
Exchange 

1286:1995 

Informational 

(Approved) 

iHB' 

■  BOfflC 

iy:  , 

UdbumuI 

1 

ISO 

«MZ 

{t»S, 

iliilil 

■  ■> : 

BHBgg  - 
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(IWO 

— 

MB— 

IlillilSII 

(PC 

ISO 
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Standard 

Sponsor 

Standard 

Standard 

Status  I 

Type 

BBSS 

Reference 

PH 

3.14.1.1.2  Alternative  specifications.  Alternative  character  coding  schemes  include  Encoded 
Binary  Decimal  (EBCDC)  and  the  Macintosh  character  set 

3.14.1.1.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.14.1.1.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.14.1.1.5  Related  standards.  The  following  standards  are  related  to  coded  character  set 
standards: 

a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  Optical  Character  Recognition  (OCR)  Character  Code  Sets: 

(1)  SO  1073-1:1976:  Alphanumeric  character  sets  for  optical  recognition-  Part 
1:  Character  set  OCR- A  -  Shapes  and  dimensions  of  the  printed  image 

(2)  SO  1073-2: 1976:  Alphanumeric  character  sets  for  optical  recognition-  Part 
2:  Character  set  OCR-B  -  Shapes  and  dimensions  of  the  printed  image 

(3)  SO  1831:1980:  Printing  specifications  for  optical  character  recognition 

(4)  SO  2033:1983:  Information  processing  —  Coding  of  machine  readable 
characters  (MICR  and  OCR) 

c.  Magnetic  Ink  Character  Recognition  (MICR)  Character  Sets 

(1)  SO  2033:1983:  Information  processing  --  Coding  of  machine  readable 
characters  (MICR  and  OCR) 

(2)  SO  1004:1995:  Information  Processing  -  Magnetic  ink  character 
recognition  -  Print  specifications 

3.14.1.1.6  Recommendations.  ISO  6937  is  recommended  for  ordinary  English-only  alphabetic 
applications. 
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3.14.1.2  Seven-bit  coded  character  sets.  (This  BSA  appears  in  part  S,  Data  Interchange,  and 
part  14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be 
uniquely  identified  using  a  seven-bit  number  (i.e.,  128  characters  numbered  0  to  127). 

3.14.1.2.1  Standards.  Table  3.14-2  presents  standards  for  seven-bit  coded  character  sets. 


TABLE  3.14-2  Seven-bit  coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

GPC 

NIST 

Code  for  Information  Interchange,  Ita  Representations, 
SubaeU,  and  Extensions  (ASCII)  (adopts  ANSI  X3.4- 
1986/R  1992.  X3.32- 1990.  X3.41-1974) 

FIPS  PUB  1- 
2:1984 

Adopted 

(Approved) 

IPC 

ISO 

ISO  7-Bk  Coded  Character  Set  for  Information  Exchange 

646:1991 

Adopted 

(Approved) 

[PC 

ISO 

Information  Processing  -  Representation  of  the  7-Bk  Coded 
Character  Set  on  Punched  Tape 

1113:1979 

Informational 

(Approved) 

NPC 

ANSI 

Code  Extension  Technique*  for  Uae  with  the  7-Bk  Coded 
Character  Set  of  American  National  Standard  Code  for 
Information  Interchange 

X3. 41-1974 

Informational 

(Approved) 

IPC 

ISO 

Information  Processing  -  Arabic  7-Bit  Coded  Character  Set 
for  Information  Interchange 

9036:1987 

Informational 

(Approved) 

IPC 

NATO 

Parameters  and  Practices  for  the  Use  of  the  NATO  7-Bit 
Code 

STANAG  5036 

Informational 

(Approved) 

IPC 

NATO 

Interoperable  Characters  for  Teleprinters  Using  NATO  7- 
BitCode 

STANAG  5045 

Informational 

(Approved) 

ISO  646  describes  a  set  of  128  control,  alphabetic,  digit,  and  symbol  characters.  It  includes  the 
use  of  the  control  characters  and  describes  the  option  of  national  replacement  characters.  It  is  the 
standard  that  formed  the  basis  for  creating  additional  standards  that  extend  the  character  set  to 
include  many  languages.  A  variant,  ISO  646:1991  IRV,  left  open  an  additional  128  codes  to  be 
used  to  represent  symbols  for  other  languages. 

3.14.1.2.2  Alternative  specifications.  Alternative  character  coding  schemes  include  Encoded 
Binary  Decimal  (EBCDC)  and  the  Macintosh  character  set. 

3.14.1.2.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.14.1.2.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets.  FIPS  19-2,  a  catalog  of  widely  used  code  sets  that  lists 
and  briefly  describes  code  stes  in  wide  use  in  the  United  States  and  might  be  used  in  Federal  data 
systems,  may  be  helpful  to  consult. 

3.14.1.2.5  Related  standards.  The  following  standards  are  related  to  seven-bit  coded  character 
sets: 
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a.  NIST  FIPS  1 9-2:  Catalog  of  Widely  Used  Code  Sets 

b.  Optical  Character  Recognition  Character  Code  Sets 

c.  ISO  3275:1974-- Implementation  of  the  7-bit  coded  character  set  and  its  7-bit  and 
8-bit  extensions  on  3,81  mm  magnetic  cassette  for  data  interchange 

d.  ISO  6586: 1980  —  Implementation  of  the  ISO  7-bit  and  8-bit  coded  character  sets 
on  punched  cards 

e.  ISO  1113:1979--  Representation  of  the  7-bit  coded  character  set  on  punched  tape 

3.14.1.2.6  Recommendations.  FIPS  1-2,  which  adopts  the  ASCII  character  set,  is  recommended 
for  common  applications.  ISO  646  is  also  recommended. 
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3.14.1.3  Eight-bit  coded  character  sets.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be 
uniquely  identified  using  an  eight-bit  number  (typically,  256  characters  numbered  0  to  255). 

3.14.1.3.1  Standards.  Table  3.14-3  presents  standards  for  eight-bit  coded  character  sets. 


TABLE  3.14-3  Eight-bit  coded  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

NPCAPC 

ANSI/ISO/IEC 

ISO  8-Bit  Code  for  Information  Interchange  *  Structure  and 
Rule*  for  IrapiemenUtion  (8-Bit  ASCII)  (Revitioo  and 
redeticnation  of  ANSI  X3.134.1) 

4873:1991 

Adopted 

(Approved) 

IPC 

ISO/TEC 

Standardized  Coded  Graphic  Character  Seta  for  Uae  in  8- 
BitGode* 

10367:1991 

Informational 

(Approved) 

IPC 

ECMA 

8- Bit  Coded  Character  Set 

6(1991) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Coded  Character  Set  Structure  and  Rules 

43(1991) 

Informational 

(Approved) 

3.14.1 3.2  Alternative  specifications.  Alternative  character  coding  schemes  include  EBCDC  and 
the  Macintosh  character  set. 

3.14.1.3 3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.14.1.3.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.14.1.3.5  Related  standards.  The  following  standards  are  related  to  eight-bit  coded  character 
sets: 


a.  NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 

b.  OCR  Character  Code  Sets 

c.  ISO  3275: 1974-  Implementation  of  the  7-bit  coded  character  set  and  its  7-bit  and 
8-bit  extensions  on  3,8 1  mm  magnetic  cassette  for  data  interchange 

d.  ISO  6586: 1980  —  Implementation  of  the  ISO  7-bit  and  8-bit  coded  character  sets 
on  punched  cards 

3.14.1.3.6  Recommendations.  ISO  4873  is  recommended. 
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3.14.1.4  Eight-bit  single  byte  character  sets.  (This  BSA  appears  in  part  5,  Data  Interchange, 
and  part  14,  Internationalization.)  Character  sets  which  contain  only  as  many  characters  as  can  be 
uniquely  identified  using  an  eight-bit  number  in  a  single  byte  (typically,  but  not  always,  2S6 
characters  numbered  0  to  255). 

3.14.1.4.1  Standards.  Table  3.14-4  presents  standards  for  eight-bit  single  byte  character  sets. 


TABLE  3.14-4  Eight-bit  single  byte  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

iso/mc 

ISO  8-Bit  Single-Byte  Coded  Graphic  Character  Seta:  Parts 
1-9 

8859-1  to  9:1987- 

1989 

Mandated 

(Approved) 

IPC 

ISO/IF.C 

ISO  8-Bit  Single-Byte  Coded  Graphic  Character  Sets:  Part 
10:  Lada  Alphabet  Set  No.  6 

8859-10:1992 

Informational 

(Approved) 

IPC 

ECMA 

8- Bit  Single-Byte  Coded  Graphic  Character  Sets,  Latin 
Alphabets  No.  1  to  No.  4 

94(1986) 

Informational 

(Approved) 

IPC 

ECMA 

8- Bit  Single-Byte  Coded  Graphic  Character  Sets  • 
Latin/Cyrillic  Alphabet 

113(1988) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets  - 
Latin/ Arabic  Alphabet 

114(1986) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets  - 
Latin/Gieefc  Alphabet 

118(1986) 

Informational  [ 
(Approved)  l 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets  - 
Latin/Hebrew  Alphabet 

121  0  987) 

Informational  1 
(Approved)  | 

IPC 

ECMA 

8- Bit  Single-Byte  Coded  Graphic  Character Seu,  Latin 
Alphabet  No.  5 

128  0988) 

Informational 

(Approved) 

IPC 

ECMA 

8-Bit  Single-Byte  Coded  Graphic  Character  Sets  -  Latin 
Alphabet  No.  6 

144  (1992) 

Informational 

(Approved) 

ISO  8859  defines  a  set  of  191  graphic  characters  with  a  single  8-bit  byte.  It  uses  the  characters 
0x20  through  0x7F  to  represent  those  used  in  the  US-ASCII  (ISO  646)  set. 

3.14.1.4.2  Alternative  specifications.  Alternative  character  coding  schemes  include  EBCDC  and 
the  Macintosh  character  set. 

3.14.1.4.3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.14.1.4.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.14.1.4.5  Related  standards.  The  following  standards  are  related  to  eight-bit  single  byte 
character  sets; 
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NIST  FIPS  19-2:  Catalog  of  Widely  Used  Code  Sets 
Optical  Character  Recognition  Character  Code  Sets 

3.14.1.4.6  Recommendations.  ISO  S8S9,  parts  1-9,  is  recommended. 
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3.14.1.5  Control  functions.  (This  BSA  appears  in  part  S,  Data  Interchange  and  part  14, 
Internationalization.)  This  service  area  is  for  definition  and  coding  of  control  functions  for 
inclusion  in  character  sets. 

3.14.1.5.1  Standards.  Table  3.14-5  presents  standards  for  control  functions. 


TABLE  3.14-5  Control  functions  standards 


Standard 

Type 

Sponsor 

.  Standard 

Standard 

Reference 

IPC 

ISO/TEC 

Cortfrot  fraction  for  ISO  7-Bil  and  8-Bit  Coded  Character 
Set! 

6429:1992 

Adopted 

(Approved) 

GPC 

NIST 

Additional  Control*  for  U»e  with  American  National 
Standard  Code  for  Information  Interchange  (adopt*  ANSI 
X3.64-1979/R1990) 

FIPS  PUB  86:1981 

Infoimational 

(Approved) 

IPC 

ISO 

Information  Proceaaipg  -  Graphical  Repcetmtationi  for  the 
Control  Character*  of  the  7  Bit  Coded  Character  Set 

2047:1975 

Infoimational 

(Approved) 

IPC 

ISO 

Bibliographic  control  chamcten 

6630:1986 

Infoimational 

(Approved) 

IPC 

BCMA 

Control  fraction*  for  Coded  Set* 

48(1991) 

Infoimational 

(Approved) 

(■■pi 

(CumM) 

ISO  6429  defines  7-bit,  7-bit  extended,  8-bit,  and  8-bit  extended  character  set  control  functions. 
3.14.1.5 2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.14.1.5  J  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.1.5.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 

3.14.1.5.5  Related  standards.  There  are  no  related  standards. 

3.14.1.5.6  Recommendations.  ISO  6429  is  recommended. 
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3.14.1.6  Character  set  conversion.  (This  BSA  appears  in  part  5,  Data  Interchange,  and  part  14, 
Internationalization.)  Character  set  conversion  deals  with  the  problem  of  translating  ffom  one 
character  set  to  another. 

3.14.1.6.1  Standards.  Table  3.14-6  presents  standards  for  character  set  conversion. 


TABLE  3.14-6  Character  set  conversion  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Coovenioa  Between  the  Two  Coded  Chirader  SeU  of  ISO 
646  end  ISO  6937-2  end  fee  CCITT  Iatemarioaei 
Tctotnefa  Alphabet  No,  2  OTA2) 

6936:1988 

Informational 

(Approved) 

,  MM 

iisil 

r-'  '  '  :  •  ••••  '  "-■•'s  \  ..  '  ',  V 

§jg^rf  ■  ■  / 

jjsaii 

13 

ISO  6936  specifies  conversion  between  the  58  character  ITA2  set  and  the  128  character  ISO  646 
set. 

3.14.1.6.2  Alternative  specifications.  There  are  alternative  specifications  that  are  sometimes 
necessary: 


a.  Mac  to  ASCII 

b.  EBCDC  to  ASCII 

3.14.1.6  .3  Standards  deficiencies.  The  greatest  deficiency  any  of  these  standards  have  is  narrow 
applicability  to  a  single  application  or  language  or  no  standard  means  of  translation  from  set  to 
set. 

3.14.1.6.4  Portability  caveats.  Character  sets  are  generally  portable,  but  there  are  sometimes 
questions  about  conversion  between  sets. 

3.14.1.6.5  Related  standards.  The  following  standards  are  related  to  character  sets  conversion: 

a.  Transliteration  standards. 

3.  '..1.6.6  Recommendations.  There  are  no  recommendations.  Character  set  conversion 
standards  depend  on  which  sets  are  involved. 


April  7,  1997 


3.14-9 


Version  3. 1 


Information  Technology  Standards  Quittance 


Intomatinn»1i»tinn  Services 


3.14.1.7  Code  extension  techniques.  (This  BSA  appears  in  part  3,  Data  Interchange,  and  part 
14,  Internationalization.)  There  is  also  a  need  to  define  standard  techniques  for  expanding  the 
number  of  characters  represented  by  a  character  set  Switching  between  character  sets  in  mid¬ 
string  is  done  by  escape  sequences. 

3.14.1.7.1  Standards.  Table  3.14-7  presents  standards  for  code  extension  techniques. 


TABLE  3.14-7  Code  extension  techniques  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/IEC 

Character  Code  Structure  and  Extension  Techniques 

2022:1994 

Adopted 

(Approved) 

IPC 

ISO 

3275:1974 

Informational 

(Approved) 

IPC 

ISO 

Extern  ion  of  the  Latin  Alphabet  Coded  Character  Set  for 
Bibliographic  Information  Interchange 

5426:1983 

Infoimatinna] 

(Approved) 

IPC 

ISO 

Extern  ion  of  the  Cyrillic  Alphabet  Coded  Character  Set  for 
Bibliographic  Information  Interchange 

5427:1984 

informational 

(Approved) 

IPC 

ISO 

Greek  Alphabet  Coded  Character  Set  for  Bibliographic 
Information  Interchange 

5428:1984 

Infoimational 

(Approved) 

IPC 

ISO 

Documentation  -  African  Coded  Character  Set  for 
Bibliographic  Information  Interchange 

6438:1983 

Informational 

(Approved) 

IPC 

ECMA 

Code  Extension  Techniques 

35(1994) 

Informational 

(Approved) 

MBlllllI 
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3.14.1.7.2  Alternative  specifications.  Alternative  specifications  would  include  other,  larger, 
forms  of  character  sets  (8-bit  instead  of  7-bit,  or  multiple-octet  sets  instead  of  8-bit). 

3.14.1.7.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.1.7.4  Portability  caveats.  Few  systems  support  the  ISO  2022  encoding  architecture  because 
escape  sequences  present  difficulties  to  processing. 

3.14.1.7.5  Related  standards.  There  are  no  related  standards. 
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3.14.1.7.6  Recommendations.  ISO  2022  is  recommended. 
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3.14.1.8  Universal  character  sets.  (This  BSA  appears  in  part  3,  Data  Interchange,  and  part  14, 
Internationalization.)  Universal  character  sets  are  an  approach  to  defining  the  broadest  possible 
character  set  This  involves  using  more  than  an  8-bit  code.  Use  of  a  16-bit  code  allows  for  a 
character  set  of  32,768  characters,  which  is  sufficient  to  cover  several  complete  alphabets, 
including  accented  letters.  The  object  of  UCS  is  to  represent  the  written  form  of  world  languages 
unambiguously  to  facilitate  information  interchange 

3.14.1.8.1  Standards.  Table  3.14-8  presents  standards  for  universal  character  sets. 


TABLE  3.14-8  Universal  character  sets  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

IPC 

ISO/IEC 

UnivamJ  Multipte-Otfa  Coded  Character  Set  (UCS),  Part 
1.  Architecture  and  Buie  Multilingual  Plane  (with 
Technical  Coniceodum  1: 1996) 

10646*1:1993 

Mandated 

(Approved) 

CPC 

XJOptn 

Univereal  Multiple-Octet  Coded  rvarartM-  Set  Coexirteoce 
god  Migration 

E401  (3/94) 

Info  rotational 
(Approved) 

CPC 

Unicode 

Congo  itiian 

Unicode  version  1.1 

UCS-2 

Informational 

(Approved) 

MSB* 

— re — 

“~85 

jjMgr  ;  a- ""owv  sy  «vk  -w  w y y 

OTPWMiK it.  < .  a • ; : 

liilSIl 

Hi 

ISO  10646  is  an  extension  of  ISO  8859.  A  separate  part  of  8859  is  defined  for  a  variety  of 
character  sets.  The  10646  is  multiple-octet  character  set  that  can  be  encoded  using  8-,  16-,  or  32- 
bit  character  sizes.  All  existing  character  sets  in  8859  are  included  as  pages  in  the  10646 
encoding,  along  with  virtually  all  known  characters  on  the  planet  The  10646  is  effectively  the 
dictionary  of  coded  character  sets. 

Unicode  is  an  implementation  of  ISO  10646  that  defines  a  set  of  16-bit  characters  and  is  not 
exactly  a  superset  of  8859. 

3.14.1.8.2  Alternative  specifications.  There  are  no  alternatives  for  a  universal  character  set. 

3.14.1.8.3  Standards  deficiencies.  Only  a  small  number  of  modem  languages  are  unrepresentable 
by  these  satndards,  but  are  expected  to  be  supported  soon. 

3.14.1.8.4  Portability  caveats.  The  portability  problems  with  universal  character  sets  involve 
their  multi-byte  nature.  Translation  to  and  from  single-byte  sets  is  full  of  chances  for  errors. 

3.14.1.8.5  Related  standards.  There  are  no  related  standards. 
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3.14.1.8.6  Recommendations.  If  multiple-octet  representations  (16-  or  32-bit)  of  characters  are 
required,  ISO  10646  is  recommended. 
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3.14.1  S  Currency  and  funds  representation.  (This  BSA  appears  in  part  5,  Data  Interchange, 
and  part  14,  Internationalization.)  Covers  characters  for  and  the  representation  of  currency  and 
monetary  values. 

3.14.1.9.1  Standards.  Table  3.14-9  presents  standards  for  currency  and  funds  representation. 


TABLE  3.14-9  Currency  and  funds  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

m 

IPC 

ISO 

Code*  for  the  RepreaenUtion  of  Currmciei  and  Fundi 

4217:1990 

Informational 

(Approved) 

3.14.1.9.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.14.1.9.3  Standards  deficiencies.  Deficiencies  in  the  standard  are  unknown. 

3.14.1.9.4  Portability  caveats.  Portability  problems  in  the  standard  are  unknown. 

3.14.1.9.5  Related  standards.  Numerical  value  representation  standards  and  internationalization 
locale  specifications  are  related. 

3.14.1.9.6  Recommendations.  ISO  4217  is  recommended. 


April  7,  1997 


3.14-14 


Version  3.1 


Information  Technology  Standards  Guidance 


Intrrnarionaliratinn  Services 


3.14.1.10  Country  name  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  These  standards  provide  for  a  short  character  combination  that  can 
be  used  to  represent  the  names  of  countries. 

3.14.1.10.1  Standards.  Table  3.14-1 1  presents  standards  for  country  name  representation. 


TABLE  3.14-10  Country  name  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

NIST 

Countrie*,  Depeodendea,  Area*  of  Special  Sovereignty  and 
their  Principal  AdmhiaUarive  Divisions 

FIPS  PUB  IO-4 
April  1995 

Informational 

(Approved) 

GPC 

NIST 

FIPS  PUB  104-1 

Informational 

(Approved) 

IPC 

ISO 

Code*  for  Repfeeentarion  of  Naraei  of  Countries 

3166:1993 

Informational 

(Approved) 

ISO  3166  defines  a  2-letter,  a  3-letter,  and  a  numeric  code  for  each  country.  The  2-letter  names 
are  well-known  and  accepted  as  internet  domain  names.  The  3-letter  codes  are  ''ften  used  in 
international  sports. 

3.14.1.10.2  Alternative  specifications.  Alternative  specifications  would  include  the  international 
codes  to  designate  the  country  of  registration  of  automobiles. 

3.14.1.103  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 
3.14.1.10.4  Portability  caveats.  Portability  problems  with  the  existing  standards  are  unknown. 
3.14.1.103  Related  standards.  There  are  no  related  standards. 

3.14.1.10.6  Recommendations.  There  is  no  recommendation. 
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3.14.1.11  Representation  of  human  sexes.  This  BSA  concerns  the  uniform  representation  of 
human  sexes  for  the  interchange  of  information. 

3.14.1.11.1  Standards.  Table  3. 14- 12  presents  standards  for  representation  of  human  sexes. 


TABLE  3.14-11  Representation  of  human  sexes  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

ISO 

Representation  of  Human  Sexc* 

5218:1977 

Informational 

(Approved) 

3.14.1.11.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.14.1.113  Standards  deficiencies.  ISO  S218  does  not  meet  the  requirements  of  specific 
medical  or  scientific  applications. 

3.14.1.11.4  Portability  caveats.  ISO  5218  does  not  prescribe  file  sequences,  storage,  media, 
programming  languages,  or  other  featur' s  of  information  processing  to  be  used  in  its 
implementation. 

3.14.1.113  Related  standards.  No  related  standards  have  been  identified. 

3.14.1.11.6  Recommendations.  ISO  5218  is  recommended  for  use. 
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3.14.1.12  Representation  of  names  of  languages.  (This  BSA  appears  in  part  S,  Data 
Interchange,  and  part  14,  Internationalization.)  This  BSA  presents  standards  for  code  to  represent 
the  names  of  languages. 

3.14.1.12.1  Standards.  Table  3.14-13  presents  standards  for  representation  of  names  of 
languages. 


TABLE  3.14-12  Representation  of  names  of  languages  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO 

Code  for  tbe  Reprotenubon  of  Name*  of  Language* 

639:1988 

Inform*tion*J 

(Approved) 

NPC 

ANSI/NISO 

Coded  for  RepreaenUban  of  for  Information 

IntoidMttte 

Z39.53 

Inform  ntxwul 
(Approved) 

3.14.1.12.2  Alternative  specifications.  Alternative  specifications  may  include  abbreviations  in 
common  use  in  entomology. 

3.14.1.123  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.1.12.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.14.1.123  Related  standards.  The  following  standards  are  related  to  representation  of  names  of 
languages: 

a.  ISO  9: 1 995:  Transliteration  of  Cyrillic  Characters  into  Latin  Characters  -  Slavic 
and  Non-Slavic  Languages 

b.  ISO  233-2: 1993:  Information  and  documentation  -  Transliteration  of  Arabic 
Characters  into  Latin  Characters  -  Part  2:  Arabic  Language  -  Simplified 
Transliteration 

c.  ISO  3602: 1989:  Documentation  -  Romanization  of  Japanese  (kana  script) 

d.  ISO  DIS  1 4962:  ASCII  encoded  English 
3.14.1.12.6  Recommendations.  ISO  639  is  recommended. 
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3.14.1.13  Date  and  time  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  Date  and  time  representation  and  storage  require  consideration  and 
standardization.  Problems  include  representation  of  twelve  or  twenty-four  hour  time,  the  order  in 
which  the  day  and  month  are  presented,  and  dropping  of  the  century  digits  from  the  year. 

3.14.1.13.1  Standard.  Table  3.14-13  presents  standards  for  date  and  time  representation. 


TAB1.E  3.14-13  Pate  and  time  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

OPC 

DOD 

Defense  Data  Dictionary  System  (DDDS),  Vernon  3.2, 
May  1996 

DDDS  Ver.  3.2 

Mandated 

(Approved) 

GPC 

NIST 

Representation  of  Calendar  Dele  and  Ordinal  Date  for 
Information  Interchange  (adopts  ANSI  X3.30- 
1985/R199I) 

jjj*l 

Informational 

(Approved) 

OPC 

NIST 

Representation  of  Local  Time  nf  the  Day  for  Information 
Exchange  (adopt!  ANSI  X3.43-1986) 

FIPS  PUB  58- 
1:1988 

Informational 

(Approved) 

GPC 

NIST 

Representations  of  Universal  Time,  Local  Time 
Differentials,  and  US  Tune  Zone  References  for 
Information  Intenhane  (Adopts  ANfl  X3.51- 1979) 

FIPS  PUB  39:1979 

Informational 

(Approved) 

IPC 

ISO 

Representation  of  Dates  and  Tunes 

8601:1988 

Informational 

(Approved) 

NPC 

ANSI 

Representation  of  Calendar  Date  and  Ordinal  Date  for 
Information  Interchange 

X3.  30-1983 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Representation  of  Local  Time  of  Day  for  Information 
Interchange 

X3.  43-1986 
(R1992) 

Informational 

(Approved) 

NPC 

ANSI 

X3.  51-1994 

Informational 

(Approved) 

NPC 

ANSI^IA 

Source  and  Date  Code  Marking 

476- A:  1987 

Informational 

(Approved) 

3.14.1.13.2  Alternative  specification.  There  are  no  other  available  specifications. 

3.14.1.13.3  Standard  deficiencies.  In  the  early  days  of  computer  technology,  information 
storage  space  was  at  a  premium.  Engineers  saved  space  by  using  only  the  last  two  digits  of  the 
year  rather  than  using  full  four-digit  year  representation  since  they  did  not  anticipate  that  existing 
systems  would  still  be  in  operation  in  the  year  2000.  This  is  a  problem  to  be  kept  in  mind  during 
data  design  for  information  systems  and  their  databases.  The  internal  representation  of  the  year 
and  dates  is  expected  to  cause  enormous  difficulties  as  the  year  2000  arrives. 


3.14.1.13.4  Portability  caveats.  The  difference  between  a  little-endian  (i.e.,  1 1  May  1995),  a  big- 
endian  (i.e.,  1995  May  1 1),  and  mixed  mode  (i.e.,  May  11, 1995)  date  representation  can  be  a 
portability  problem  for  systems.  The  stated  DoD  data  element  for  date  format  is 
"YYYYMMDD"  where  YYYY  is  the  year,  MM  is  the  month,  and  DD  is  the  day.  NIST  highly 
recommends  that  four-digit  year  elements  be  used  and  that  two-digit  year  elements  NOT  be  used 
for  data  interchange.  On  March  25,  1996  NIST  published  a  change  notice  to  FIPS  4-1  that  highly 
recommends  four-digit  year  elements,  and  suites  that  two-year  elements  specified  in  ANSI 
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X3.30:1985  (R1991)  should  not  be  used  for  the  purpose  of  any  data  interchange  among  U.S. 
Government  agencies. 

3.14.1.13.5  Related  standards.  The  following  standard  is  related  to  date  and  time  representation: 
a.  NIST  FIPS  34,  Guide  for  the  Use  of  International  System  of  Units  in  FIPS  PUBS 

3.14.1.13.6  Recommendations.  For  purposes  of  data  interchange,  DoD  requires  that  year, 
month,  and  day  be  represented  as  'YYYYMMDD'. 
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3.14.2  Cultural  convention  services.  These  services  provide  the  capability  to  store  and  access 
rules  and  conventions  for  cultural  entities  maintained  in  a  cultural  convention  repository. 

3.14.2.1  Numerical  value  representation.  (This  BSA  appears  in  part  5,  Data  Interchange,  and 
part  14,  Internationalization.)  Numerical  value  representation  deals  with  the  presentation  of 
numerical  values  as  character  strings  in  machine-  and  human-  readable  form. 

3.14.2.1.1  Standards.  Table  3.14-14  presents  standards  for  numerical  value  representation. 


TABLE  3.14-14  Numerical  value  representation  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

[PC 

ISO 

Representation  of  Numerical  Value*  in  Chancier  String* 
for  Information  Interchange 

6093:1985 

Informational 

(Approved) 

ISO  6093  specifies  three  presentations  of  numerical  values  as  w;  •;  '■  machine- 

readable  form  for  data  interchange. 

3.14.2.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.14.2.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.2.1.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.14.2.1.5  Related  standards.  The  following  standards  are  related  to  numerical  value 
representation: 


a.  Representation  of  currency 

b.  Representation  of  date/time 

c.  Localization 

d.  ANSI  X3.50  1986/R1992;  Representation  for  U.S.  Customary,  SI,  and  other  Units 
to  be  used  in  Systems  with  limited  character  sets 

e.  ISO  2955: 1993  -  Representation  of  SI  and  other  Units  in  Systems  with  limited 
Character  Sets 

3.14.2.1.6  Recommendations.  ISO  6093  is  recommended. 
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3.14.22  Customization  to  local  norms.  (This  BSA  appears  in  part  3,  User  Interface,  part  13, 
Human  Factors,  and  part  14,  Internationalization.)  Customization  to  local  norms  involves 
modification  of  the  key  mapping  to  accommodate  the  local  language  and  display  of  data  in  the 
commonly-used  format  (e.g.,  numbers,  dates,  time). 

3.14.2.2.1  Standards.  Table  3.14-15  presents  standards  for  customization  to  local  norms. 


TABLE  3.14-15  Customization  to  local  norms  standards 


Standard 

Type 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

GPC 

DOD 

Human-Computer  Interface  (HCI)  Style  Guide 

TAFIM  Volume  8, 
Version  3.0:  1996 

Mandated 

(Approved) 

CPC 

XJOpm 

In teaudonali taboo  Guide,  vcnion  2 

G304  (7/93) 

Informational 

(Approved) 

CPC 

X/Op «n 

Locate  Registry  Procedure* 

G303  (1993) 

Informabonal 

(Approved) 

CPC 

OSF 

Motif  1.2  (consistent  with  X/Open's  NLS  ipedficabons  A 
alio  double- byte  character  seta) 

Motif  1.2 

Informational 

(Approved) 

CPC 

MITX 

Cocao  rbum 

X  Wmdow  Syrian  (X  foot  manager-  inductee  double-byte 
diameter  aete) 

X11R5 

Informabonal 

(Approved) 

NPC 

ANSl/HFS 

American  National  Standard  for  Human  Factor* 
Engineering  of  Vianal  Diaplay  Terminal  Woriuterioni 

100-1988 

Informabonal 

(Approved) 

GPC 

DOD 

Military  Standard  Keyboard  Arrangements 

MIL-STD-1280. 
Notice  1. 1969 

Informabonal 

(Approved) 

GPC 

DOD 

User£omputer  Interface 

MIL- STD- 1801  29 
May  1987 

Informabonal 

(Approved) 

GPC 

DOD 

Human  Engineering  Performance  Requirement*  for 
Systems 

MIL-STD-1800A 

10  Oct.  1990 

Informabonal 

(Approved) 

GPC 

DOD 

DOD  Handbook,  Human  Engineering  Guidelinea  for 
Management  Information  Sy  items 

MIL-HDBK-761A 
30  Sep.  1989 

Informabonal 

(Approved) 

GPC 

DOD 

Guideline*  for  Designing  User  Interface  Software 

ESD-TR-86-278 

informabonal 

(Approved) 

GPC 

DOD 

Department  of  Defense  Intelligence  Information  Systems 
Style  Guide 

DODIIS  Style 

Guide,  10/91 

Informabonal 

(Approved) 

GPC 

DOD 

Air  Force  Intelligence  Date  Handling  System  (IDHS)  Style 
Guide 

IHy  ' 

Informational 

(Approved) 

GPC 

DOD 

Human  Factors  Guidelines  for  (he  Army  Tactical 
Command  and  Control  System  (ATCCS)  Soldier-Machine 
Interface 

ATCCS  Guidelines 
v.l.0andv.2.0, 
1990  and  1992 

Informational 

(Approved) 

GPC 

DOD 

The  User  Interface  Specifications  for  Navy  Command  and 
Control  Systems 

Navy  CCS.  Version 
1.1,1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Design  Criteria  for  Military  Systems, 
Equipment  ind  Facilities 

MT  *;TD-1472D 
Notice  2,  30  June 
1992 

Informational 

(Approved) 

GPC 

DOD 

Human  Engineering  Guideline*  for  Management 
Information  Systems 

DOD-HDBK-71A 
(DOD  1989c) 

Informational 

(Approved) 

CPC 

X/Open 

Distributed  Internationalisation  Services 

S213  (11/92) 

Informational 

(Approved) 
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Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

CPC 

X/Open 

Intemjbonrfi  ration  of  lotametworting  Sperificuioos 

S302  (4/93) 

Informational 

(Approved) 

CPC 

WOp«o 

File  System  Safe  UCS  Transformation  Format  (FSS-UTF) 

P316  (1993) 

hfonnatiooal 

(Approved) 

CPC 

WQptn 

Syum  IMafice  and  Hudm,  tune  3 

C212  (3/92) 

Infonsafional 

(Approved) 

CPC 

X/Qp « 

Supplementary  Deftntiofli,  Iuue  3 

C213  (3/92) 

lofomutional 

(Approved) 

CPC 

X/Op« 

Universal  Mu  tiple-Octet  Coded  Charade*  Set  Coexiteeoc* 
and  Migration 

E401  (3/94) 

Informational 

(Approved) 

NPC 

ANSI/S  AE 

Human  Interface  Design  Methodology  for  Integrated 
Display  Symbology 

ARP  4155(1990) 

Informational 

(Approved) 

GPC 

DOD 

Human  Eogineecwig  Requirements  for  Military  Syatemi. 
Equipment,  aod  Facilities 

MIL  jTD-46I55B 
26  May  1994 

Informational 

(Approved) 

CPC 

X/Op eo 

Single  Unix  Specification  (Spec.  1 170),  Syrian  Interface 
Definitiooi,  Iiaue  4,  Vernon  2  (put  of  XP04) 

C434  (9/94) 

Informational 

(Approved) 

CPC 

X/Open 

Single  Unix  Specification  (Spec.  1 170),  System  Interface* 
aod  Headers,  Issue  4,  Vera  ion  2,  (Part  of  XPG4) 

C435  (9fl4) 

Informational 

(Approved) 

CPC 

X/Open 

Locale  Registry  Procedures,  Version  2 

0502  (5/95) 

Informational 

(Approved) 

CPC 

OSF 

Motif 

Motif  2.0 

Informational 

(Approved) 
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DODI  8120  mandates  use  of  the  DOD  HCI  Style  Guide. 

Motif  1.2  is  the  current  version  of  the  OSF  specification  for  GUI  behavior  and  appearance  and 
programming  and  data  interfaces.  XI 1R5  is  the  current  release  of  Version  1 1  of  the  X  Windows 
standard. 

3.14.2.2.2  Alternative  specifications.  Several  applicable  consortia  or  de  facto  style  guides  are 
available  for  internationalization.  However,  conformance  with  one  or  more  the  style  guides  listed 
below  does  not  guarantee  conformance  with  ergonomic  standards: 

a.  The  Windows  Interface:  An  Application  Design  Guide  (Microsoft) 
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b.  Object-Oriented  Interface  design:  IBM  Common  User  Access  Guidelines  (IBM) 

c.  Macintosh  Human  Interface  Guidelines  (Apple  Computer). 

3.14.2.23  Standards  deficiencies.  Currently,  conformance  to  parts  12-17  of  the  ISO  9241 
standard  is  on  a  part-by-part  basis.  There  is  concern  that  the  overal  standard  may  thus  fail  to 
address  potential  ergonomic  problems  arising  from  interactions  between  the  user  interface 
elements  coveted  by  the  individual  parts. 

3.14.2.2.4  Portability  caveats.  Although  Morif  supports  the  X/Open  Native  Language  System,  it 
also  supports  a  number  of  its  own  internationalization  extensions  which  makes  it  compatible  with 
some  legacy  applications  (e.g.,  OpenLook). 

NIST  FIPS  158-1  (User  Interface  Componenet  of  the  Applications  Portability  Profile)  mandates 
the  use  of  the  X  Window  protocol,  X  library,  and  X  toolkit  intrinsics.  IEEE  P1201.2,  when 
completed,  is  intended  to  increase  the  level  of  user  interface  consistency  (and  thus  user  interface 
portability)  across  X  Windows-based  environments.  There  are  potential  conflicts  here. 

The  DOD  HCI  Style  Guide  is  based  on  (and  intended  to  supersede)  the  Army,  Navy,  Air  Force, 
and  DODDS  Style  Guides  cited  in  the  table  above.  The  goal  of  this  effort  is  to  minimize 
unnecessary  user  interface  diversity  across  DOD  systems.  There  are  potential  problems  with 
systems  designed  to  accommodate  different  style  guides. 

3.14.2.2.5  Related  standards.  The  following  standards  are  related  to  cultural  convention 
services: 

a.  X/Open  Internationalisation  Locale:  L001  (1994):  ja_JP  -  Japanese  for  Japan. 

b.  X/Open  Internationalisation  Locale:  L002  (1994):  da_DK  -  Danish  for  Denmark. 

c.  X/Open  Internationalisation  Locale:  L003  (1994):  de_AT  -  German  for  Austria. 

d.  X/Open  Internationalisation  Locale:  L004  (1994):  en_DK  -  English  for  Denmark. 

e.  X/Open  Internationalisation  Locale:  L005  (1994):  fo_FO  -  Faroese  for  the  Faroes. 

f.  X/Open  Internationalisation  Locale:  L006  (1994)  is_lS  -  Icelandic  for  Iceland. 

g.  X/Open  Internationalisation  Locale:  L007  (1994)  kl_GL  -  Greenlandic  for 

Greenland. 

h.  X/Open  Internationalisation  Locale:  L008  (1994)  lt_LT  -  Lithuanian  for  Lithuania. 

i.  X/Open  Internationalisation  Locale:  L009  (1994):  lv_LV  -  Latvian  for  Latvia. 
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j.  X/Open  Internationalisation  Locale:  L010  (1994):  de_CH  -  German  for 
Switzerland. 

k.  X/Open  Internationalisation  Locale:  L01 1  (1994):  de_DE  -  German  for  Germany. 

L  X/Open  Internationalisation  Locale:  L012  (1994):  en_GB  -  English  for  Great 

Britain. 

m.  X/Open  Internationalisation  Locale:  L013  (1994):  en_IE  -  English  for  Ireland. 

n.  X/Open  Internationalisation  Locale:  L014  (1994):  en_US  -  English  for  the  U.S.A. 

o.  X/Open  Internationalisation  Locale:  LOIS  (1994):  hu_HU  -  Hungarian  for 

Hungary. 

p.  X/Open  Internationalisation  Locale:  LO 1 6  ( 1 994):  it_IT  -  Italian  for  Italy. 

q.  X/Open  Internationalisation  Locale:  L017  (1994):  nl_NL  -  Dutch  for  the 
Netherlands. 

r.  X/Open  Internationalisation  Locale:  L018  (1994):  pl_PL  -  Polish  for  Poland. 

s.  X/Open  Internationalisation  Locale:  L019  (1994):  pt_PT  -  Portuguese  for 
Portugal. 

t.  X/Open  Internationalisation  Locale:  L020  (1994):  ro_RO  -  Romanian  for 
Romania. 

u.  MIL-STD-1794  (1986)  Human  Factors  Engineering  Program  for  ICBM  Systems. 

v.  MIL-STD-1908  (1992)  Definitions  of  Human  Factors  Terms. 

w.  DOD-HDBK.-763  (1987)  Human  Engineering  Procedures  Guide. 

3.14 .2.2.6  Recommendations.  Procurements  that  require  software  user  interfaces  to  be 
addressed  by  ergonomic  standards  can  require  conformance  with  standards  for  menu  structures, 
command  languages,  direct  manipulation  dialogs,  forms-based  dialogs,  windowing,  icons,  screen 
formatting,  information  coding,  and  user  guidance. 

Parts  1  and  2  of  the  ISO  9241  standard  are  informative;  parts  10  and  1 1  are  expected  to  be 
informative  on  completion.  Part  3  of  the  ISO  9241  standard  is  normative;  parts  2-9  and  12-17  are 
expected  to  be  normative  on  completion.  Conformance  with  the  overall  ISO  9241  standard  is 
based  on  conformance  with  all  normative  parts  that  apply  to  a  particular  product. 
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Procurements  must  recognize  the  difference  between  informative  and  normative  parts  of  the 
standard  in  question.  Where  possible,  both  the  informative  and  normative  parts  should  be  required 
for  the  best  implementation  of  modem  human  factors/ergonomic  thinking.  In  general, 
conformance  tests  for  informative  parts  will  not  be  available. 

The  DOD  HCI  Style  Guide  is  recommended  for  customization  to  local  norms. 
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3.143  Natural  language  support  services.  These  services  provide  the  capability  to  support 
several  languages  simultaneously. 

3.14.3.1  Keyboard  device  layout  (This  BSA  appears  in  both  part  3,  User  Interface,  and  part 
14,  Internationalization.)  Keyboard  device  layout  standards  specify  the  arrangement  of  keys  on  a 
keyboard. 

3.14.3.1.1  Standards.  Table  3.14-16  presents  standards  for  keyboard  device  layout. 


TABLE  3.14-16  Keyboard  device  layout  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISQ/FX 

Keyboard  Uyouu  for  Text  and  Office  Systems 

9993-1. .8: 1994 

Mandated 

(Approved) 

GPC 

DJD 

Military  Standard  Keyboard  Arrangements 

MJL-STD-1280, 
Nr.tice  1, 1969 

Informational 

(Approved) 

NPC 

ANSI 

Allocation  of  Letters  to  die  Keys  of  Numeric  Keypads 

Tl. 703  (1995) 

Informational 

(Approved) 

NPC 

ANSI 

Coded  Character  Sets  for  Keyboard  Arrang  emeot  in  ANSI 
X4.23-1982  and  X4.22- 1983 

X3. 114-1984 
(R1991) 

Informational 

(Approved) 

NPC 

ANSI 

Keyboard  Arrangement 

X3. 154- 1988 

Informational 

(Approved) 

NPC 

ANSI 

Alternate  Keyboard  Arrangement 

X3.207- 1991 

Informational 

(Approved) 

CPC 

XAJpen 

Key  Values  (in  Window  Management,  It  sue  3) 

XP03  Vol.  6C216 

Informational 

(Approved) 

IPC 

ISO 

Keyboard  Layouu  for  Numeric  Applications 

3791:1976 

Informational 

(Approved) 

IPC 

ISO/IEC 

Numeric  Keyboard  for  Home  Electronic  Systems  (HES) 

946:1988 

Informational 

(Approved) 
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3.14.3.1.2  Alternative  specifications.  The  only  other  available  specifications  are  proprietary. 
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3.143.13  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.3.1.4  Portability  caveats.  Portability  problems  related  to  the  existing  specifications  are 
unknown. 

3.14  3.13  Related  standards.  No  standards  are  related  to  keyboard  device  layout  standards. 

3.143.1.6  Recommendations.  Conformance  to  all  ISO  and  ISO/IEC  keyboard  specifications 
conforming  to  DIS  or  IS  levels  is  recommended.  This  is  especially  important  for  equipment  that 
will  interoperate  with  that  of  U.S.  allies  (e.g.,  NATO). 
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3.14.4  Related  standards' and  programs.  This  MLSA  includes  services  supporting 
internationalization  indirectly. 


3.14.4.1  Character  set  registration.  (This  BSA  appears  in  part  3,  Data  Interchange,  and  part 
14,  Internationalization.)  Character  set  registration  provides  a  mechanism  for  identifying  and 
defining  graphic  character  sets 


3.14.4.1.1  Standards.  Table  3.14-17  presents  standards  for  character  set  registration. 


TABLE  3.14-17  Character  set  registration  standards 


Standard 

Type 

Sponsor 

Standard 

Standard 

Reference 

Status 

DoD 

(Lifecycle) 

IPC 

ISO/TEC 

Registration  of  Repertoire*  of  Graphic  Character*  from 
ISO/IEC  10367 

7350:1991 

Informational 

(Approved) 

IPC 

ISO 

Procedure  for  registration  of  escape  sequences 

2375:1985 

Informational 

(Approved) 

ISO  7350  specifies  procedures  for  preparing,  registering,  publishing,  and  maintaining  the  register 
of  graphic  character  sets  and  procedures  for  assigning  identifiers  to  the  sets. 

3.14.4.1.2  Alternative  specifications.  There  are  no  alternative  specifications. 

3.14.4.1.3  Standards  deficiencies.  Deficiencies  in  the  existing  standards  are  unknown. 

3.14.4.1.4  Portability  caveats.  Portability  problems  in  the  existing  standards  are  unknown. 

3.14.4.1  £  Related  standards.  The  following  standards  are  related  to  character  set  registration: 

a.  Character  set  standards 

b.  Localization  standards 

c.  Symbols  for  use  with  data  such  as  currency,  date,  time,  numerical  values 
3.14.4.1.6  Recommendations.  There  are  no  recommendations. 
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